Automatic commit of irc logs

[matches/MCTX3420.git] / irc / log

--- Log opened Sat Aug 03 15:12:13 2013
15:12 -!- matches [[email protected]] has joined #mctxuwa_softdev
15:12 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
15:12 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
15:12 < matches> Good idea with the IRC channel
15:12 < matches> I'm Sam Moore by the way
15:14 < Callum_> Hey. Finally someone else 
15:19 < Callum_> Hmm should probably close the app so my phone has enough battery to get me home. 
15:21 -!- Callum_ [[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
15:45 -!- james__ [[email protected]] has quit [Ping timeout]
15:51 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
15:51 -!- matches [[email protected]] has left #mctxuwa_softdev []
--- Log closed Sat Aug 03 15:51:28 2013
--- Log opened Sat Aug 03 15:51:51 2013
15:51 -!- matches [[email protected]] has joined #mctxuwa_softdev
15:51 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
15:51 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
15:52 -!- matches changed the topic of #mctxuwa_softdev to: MCTX3420 UWA
15:52 -!- matches changed the topic of #mctxuwa_softdev to: MCTX3420 UWA - Team 4 (Software, Firmware, GUI)
16:40 -!- matches changed the topic of #mctxuwa_softdev to: MCTX3420 UWA - Team 4 (Software and stuff)
16:52 -!- james__ [[email protected]] has joined #mctxuwa_softdev
16:54 -!- You're now known as sam__
16:54 < sam__> Yuck
16:54 -!- You're now known as sam_moore
16:55 < sam_moore> That works
16:55 < james__> Yuck?
16:55 < james__> Oh right
16:55 < james__> all the underscores?
16:55 < sam_moore> Yeah
16:55 < james__> its a bit of a pain
17:01 < sam_moore> I think you might be able to comment on changes if you use github
17:01 < sam_moore> I'll see if I can copy the repository there
17:01 < james__>  you should be able to
17:01 < sam_moore> It does seem useful
17:01 < james__> its what it waas designed for really
17:01 < sam_moore> Yeah, gitweb is a bit more limited
17:02 < james__> Yeah.  Or at least the features aren't as easily accesible as in github
17:10 < sam_moore> I'll clone the repository into github now
17:24 < james__> Need to be logged in but it looks like you can comment
18:13 -!- Callum [[email protected]] has joined #mctxuwa_softdev
20:38 -!- Callum [[email protected]] has quit [Ping timeout]
22:01 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
22:15 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
--- Day changed Sun Aug 04 2013
10:43 -!- Callum [[email protected]] has joined #mctxuwa_softdev
10:47 < Callum> morning
10:49 < sam_moore> Hi
10:52 < Callum> What is there we need to get done? i haven't really done anything yet
10:53 < sam_moore> We need to write a progress report on what we need to get done :P
10:53 < Callum> Thats the other thing i wanted to know, is the progress report per person or per group?
10:53 < sam_moore> It's per group, and it only has to be one page
10:54 < Callum> I'v had a quick look through the stuff online and only thing i can see is the example but it looks like its per person in that
10:54 < Callum> ok, that makes things a lot easier then
10:54 < sam_moore> We are meant to have our own technical diaries with handwritten notes
10:54 < Callum> yea saw that as well
10:55 < sam_moore> So, at the meeting we sort of worked out a vague idea of what systems we'll need
10:55 < Callum> yea had a read through the meeting notes
10:56 < Callum> seemed like a solid start
10:56 < sam_moore> Yes, I think I'll do a block diagram about it
10:56 < sam_moore> Since I actually have a raspberry pi I've been playing with it
10:57 < sam_moore> No one's really done that much though, to be fair our group was only completely formed by Friday
10:57 < Callum> Well, I'm the guy that moved into the group :p
10:58 < sam_moore> Is there anything in particular you'd like to work on?
10:59 < Callum> Il have another look through the meeting notes, but i don't really have any experience working with this hardware. Just mainly C + Java, but i pick stuff up pretty quick
10:59 < Callum> well, any hardware other than what we did in embedded
11:02 < sam_moore> We need to learn more about the actual requirements of the system I think, not sure how much we can work out without talking to all the other groups
11:03 < Callum> Yea true. Might have a play around with git sometime soon to get used to it
11:03 < sam_moore> Oh, something I listed in an email was image processing, that will be important
11:05 < sam_moore> Anyway, if you can try and find something that interests you that seems useful and just write a little bit on that, it would be great
11:06 < sam_moore> Learning git would be useful, you can write about that, it doesn't matter if Rowan does it as well since we'll all need to learn more
11:07 < sam_moore> I know enough of git to work on my own projects, but there are a lot of features designed for group work that I've never used
11:37 -!- james__ [[email protected]] has joined #mctxuwa_softdev
11:42 < Callum> Sam, I think i got a different ssh key from github; So if im going to use this you'll likely need to add it
11:42 < Callum> And hey James
11:43 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
11:45 -!- Callum [[email protected]] has quit [EOF From client]
11:59 -!- james__ [[email protected]] has quit [Ping timeout]
12:09 < sam_moore> Callum__: Ok, send it to me
12:11 < sam_moore> If you have github accounts let me know those as well
12:11 -!- james__ [[email protected]] has joined #mctxuwa_softdev
12:11 < james__> Hey
12:12 < sam_moore> Hi
12:12 < sam_moore> You guys can't see what's written in the channel whilst you're not in it, right?
12:12 < james__> How are things
12:12 < james__> Nope
12:12 < james__> Its only once you log in  that you can read it
12:13 < sam_moore> I'm messing around with git a bit, I've sent an email about the progress report
12:13 < james__> Unless you log it there isn't any way to go back to previous convos
12:13 < sam_moore> I'd like to meet at 2pm on Monday if that's possible
12:13 < james__> sounds good
12:13 < sam_moore> I'm running irssi in screen on a server, so I'll have everything logged
12:13 < sam_moore> I'll look into making the logs available on git
12:14 < Callum__> think anyone would care if i go to G19 without the safety meeting? not like we're actually doing anything.
12:14 < james__> i'm using chatzilla so there is an inbuilt log function
12:15 < james__> Don't know tbh
12:15 < sam_moore> Callum__: No, but just try not do anything unsafe or the rest of us will get the blame :P
12:15 < Callum__> well, we could just meet somewhere else. Not like we need to go there
12:16 < sam_moore> Adrian did say that we could have people visit the lab, but we are responsible for anyone we bring in without the safety course.
12:16 < sam_moore> Ok, what's another good place?
12:16 < james__> No idea
12:16 < james__> The lab is kinda nice and quite/out of the way
12:16 < Callum__> ok well it should be fine. If it's a suitable meeting location than just go with it.
12:17 < sam_moore> I don't think it will be a big deal to go in G19, just don't use any equipment. It is a good place.
12:17 < Callum__> Yea. just making sure it wont be a problem
12:18 < Callum__> Im going to get some lunch. 
12:40 < sam_moore> You need to use [email protected]:matchesucc/MCTX3420.git to commit using your ssh key
12:41 < sam_moore> If you give me your username, I think you can use https://github.com/matchesucc/MCTX3420.git
12:41 < sam_moore> You should be able to commit to git.ucc with your ssh key
12:42 < sam_moore> But I think we'll prefer github. It looks like it has more features. I'll use that as the main repository and keep git.ucc up to date in case github explodes.
12:43 < Callum__> username: Callum-
12:45 < sam_moore> Right, before you commit your changes, pull from the server
12:45 < sam_moore> If your repository is "up to date" with the server and you make changes, it is really easy
12:46 < sam_moore> If it isn't and you have changes that contradict something done on the server, we'll have to merge the repositories, and from what I've heard that's usually a pain
12:47 < sam_moore> We'll probably have to deal with it at some point.
12:48 < Callum__> how do you pull from github>
12:51 < sam_moore> Not sure how you do it in the gui, is there a "pull" or "fetch" button
12:52 < Callum__> not that i can see
12:52 < sam_moore> Hang on, I'll start windows and see if I can work out how to do it
12:53 < james__> are you logged in?
12:53 < sam_moore> Yes
12:53 < sam_moore> Cool, you can even edit the files entirely from github
12:54 < Callum__> you can?
12:54 < sam_moore> Well, I can
12:54 < sam_moore> I added Callum- as a collaborator; can you see the repository?
12:55 < Callum__> i could see it before
12:55 < Callum__> wait hang on
12:56 < james__> can you add me aswell?
12:56 < james__> username: firefields
12:57 < Callum__> i can edit it from the browser
12:57 < sam_moore> Done
12:57 < sam_moore> Excellent, that's a start
12:59 < james__> I can comment
13:00 < sam_moore> The browser editor actually looks pretty good
13:01 < sam_moore> Hmm
13:01 < sam_moore> We need to be able to pull from github to our own machines though
13:01 < sam_moore> So we can actually run code
13:02 < sam_moore> I can do it myself using the command line
13:02 < sam_moore> I'll see how to do it using the GUI
13:03 < james__> I am having a look through the documentation now trying to find it
13:07 < sam_moore> I wonder what happens when two people edit a file at the same time
13:07 < james__> Lets edit the readme?
13:08 < sam_moore> Alright.
13:08 < james__> I am currently editing
13:08 < james__> Can you get in?
13:09 < sam_moore> Yes, and it looks the same
13:09 < sam_moore> Make some changes and commit it, then I'll go and we'll see what happens
13:09 < james__> Done
13:09 < sam_moore> It says that you have committed since I started editing
13:10 < sam_moore> Whoops, but I could still overwrite it
13:11 < sam_moore> Ok, at least it gives us a warning, that's nice
13:11 < sam_moore> I think the key to this will be: 1) Try and work on different source files 2) Send lots of spam to IRC when you do stuff
13:11 < james__> Also
13:11 < james__> if you look in history my changes are still there
13:11 < sam_moore> Yeah, that's nice
13:12 < sam_moore> And I think we can go back to them
13:12 < james__> I am reading about this fork and pull method as well.  Might work well
13:13 < james__> Essentially you fork the repo. Make changes then request for it to be pulled back into the master repo 
13:13 < sam_moore> Yes, that will likely be the best way to go about it.
13:13 < james__> That way all changes can be viewed and then confirmed before going into the master copy
13:15 < james__> https://help.github.com/articles/fork-a-repo
13:15 < james__> and this https://help.github.com/articles/using-pull-requests
13:17 < sam_moore> I think in the long run it will be easier to use the command line when you work on your local machine
13:17 < Callum__> might just end up learning how to do it all from command line anyway
13:17 < sam_moore> All the tutorials seem to give the command line stuff
13:17 < Callum__> yea
13:17 < Callum__> suppose you could use the gui just to look at whats there
13:17 < sam_moore> `git add remote github [email protected]:matchesucc/MCTX3420.git`
13:17 < sam_moore> `git pull github master`
13:17 < sam_moore> Make changes
13:17 < sam_moore> `git add .`
13:18 < sam_moore> `git commit`
13:18 < sam_moore> `git push github master`
13:18 < sam_moore> Well, that's just directly going to the repository without forking it
13:19 < Callum__> is the add thing for staging?
13:19 < sam_moore> Yeah; you have to tell it what changes to stage to the commit
13:19 < Callum__> yea
13:19 < sam_moore> I think there is an option to automatically add all changed files
13:20 < sam_moore> I've always just manually done them, makes it easier to work out what I actually did before writing the commit message
13:20 < james__> Do we want to fork first
13:20 < sam_moore> Probably
13:20 < james__> That way someone can't make a change that is incorrect into the master
13:21 < sam_moore> Yes, this sounds good
13:22 < sam_moore> It won't let me fork it (probably because I'm the "owner")
13:24 < james__> I have forked succesfully
13:25 < james__> maybe branch?
13:25 < sam_moore> No, branches are different
13:25 < james__> Right...
13:25 < james__> well i made a branch for you? :P
13:26 < sam_moore> It doesn't matter if I directly edit the master repository anyway; I'll have to deal with all the pull requests before I do anything mysekf
13:27 < sam_moore> Yeah, we don't want to use branches just yet
13:28 < sam_moore> A fork is for each person working on the code; a branch is for when you want to make changes to something that might break parts of the code that already work
13:28 < sam_moore> For example: You have some really badly written code, but it does what it's meant to do
13:28 < sam_moore> So you make a branch "Improve networking code" or something like that
13:29 < sam_moore> Then you redo it, and only when you're done you merge your branch back into the master, getting rid of all the old code
13:30 < james__> Fair enough. I think i have made a pull request...
13:30 < sam_moore> Cool
13:31 < sam_moore> Now it should be in the main repository
13:32 < james__> yeah. worked
13:32 < sam_moore> I show up as the author of your changes, which is a bit silly
13:33 < Callum__> firefields opened this pull request 15 hours ago
13:33 < Callum__> what
13:34 < sam_moore> Is the clock on your local machine correct?
13:34 < Callum__> yea
13:34 < Callum__> matchesucc merged 1 commit into matchesucc:master  from firefields:master  2 minutes ago
13:34 < Callum__> it also says that
13:34 < james__> Right.... Thats weird
13:35 < sam_moore> You guys should also be able to merge the pull requests, since you're collaborators
13:36 < Callum__> alright
13:36 < james__> Yeah. Should be able to
13:36 < sam_moore> So in summary: Fork the repository, make a pull request, go and check that nothing will break horribly, and then you can merge it
13:36 < james__> pretty much
13:36 < sam_moore> Cool
13:36 < sam_moore> We should put this in the progress report
13:37 < Callum__> Yea, detailing how we plan to collaborate the code
13:38 < sam_moore> So, should I put our IRC channel log into git?
13:39 < Callum__> probably a good idea
13:39 < sam_moore> That way people who weren't in the channel can read conversations they missed 
13:39 < Callum__> unlikely be that useful but it would be good to have everything archived
13:42 < james__> Its always good to have everything archived
13:47 < Callum__> so noone else getting weird timestamps on github
13:47 < james__> not that i can see
13:48 < sam_moore> No, they all make sense to me
13:48 < Callum__> also my forked repo doesnt have the updated readme
13:48 < Callum__> iv added the upstream and tried fetch upstream and doesnt seem to do anything
13:48 < sam_moore> Try merging after the fetch
13:48 < sam_moore> fetch + merge = pull
13:49 < sam_moore> "Pull request" is a bit confusing, because you're not asking to pull from my repository; you're requesting that I pull from yours
13:49 < Callum__> yea, i got that. how do i do the merge?
13:50 < sam_moore> git merge upstream/master
13:51 < Callum__> yup that worked
13:51 < sam_moore> The GUI seems really terrible, I have no idea how to do this stuff with it
13:52 < sam_moore> I thought it might be easier if people weren't used to the command line, but there aren't that many commands
13:52 < Callum__> yea
13:52 < james__> Its easier to comment etc
13:53 < james__> But some of the functionality is horribly buried
13:53 < sam_moore> Do you get a text editor in the terminal when you want to commit?
13:54 < sam_moore> Oh well, whatever people find easiest
14:09 < Callum__> alright well i just submitted a pull request and accepted it
14:10 < sam_moore> Yep
14:10 < sam_moore> Callum- authored in 15 hours
14:11 < sam_moore> ?
14:11 < Callum__> ahahahahahaah
14:11 < sam_moore> Are you from the future?
14:11 < sam_moore> Does IRC mess with the space time continuum
14:11 < Callum__> it says 15 minutes ago for me, but the rest are 17 hjours ago
14:11 < Callum__> i must be from the future :o
14:12 < sam_moore> Someone's clock is out of skew
14:13 < sam_moore> That is really wierd
14:13 < sam_moore> You merged the pull request... before the file was changed... according to this history
14:14 < sam_moore> Oh!
14:14 < sam_moore> Is it because github is based in the US
14:14 < Callum__> but for you all the times are right apart from mine?
14:14 < Callum__> and for me all the times are wrong but mine
14:15 < sam_moore> Well it's only showing relative times
14:15 < Callum__> or do you get weird results from james as well?
14:15 < sam_moore> James times look reasonable
14:15 < Callum__> hmm. weird
14:15 < sam_moore> But notice how a lot of our stuff is on 3rd August, it's actually the 4th today
14:16 < Callum__> hmm yea
14:17 < sam_moore> I kind of think we should fix this, it's not a major issue but it will certainly be confusing
14:18 < sam_moore> Hey, wierd, the times look sensible in git.ucc
14:18 < sam_moore> http://git.ucc.asn.au/?p=matches/MCTX3420.git;a=summary
14:19 < Callum__> yea agreed 
14:19 < Callum__> and that is kinda weird
14:20 < Callum__> i cant seem to find anything in account settings for a timezone
14:21 < Callum__> Anything else we need done by tomorrow? because i have a bunch of other stuff I'd like to get done
14:21 < sam_moore> While you're in account settings, you can set your author name for commits
14:22 < sam_moore> No, there's nothing urgent at this stage
14:22 < sam_moore> It's only the first week, and we only need 1 page
14:22 < sam_moore> We can be like "Here is a page of details on how we got Git to work" if we have to
14:22 < Callum__> Yea just we need to make sure we have enough for 1 page
14:23 < Callum__> hmm, true i suppose. set up IRC + git repo + discussed an outline on what is going to be required
14:24 < Callum__> Tbh he'l likely be happy if we just give him a summary of those meeting minutes
14:25 < Callum__> Anyway i'l divert my attention for now then. If you come across anything interesting or something that can be done il stick around in the channel
14:25 < sam_moore> Ok, thanks
14:26 < sam_moore> The first automatic commit of the irc logs seems to have worked!
14:26 < sam_moore> It also copies everything to git.ucc so we have a backup
14:26 < Callum__> nice
14:27 < sam_moore> The times might be correct as well :P
14:27 < Callum__> was just like "where is it? " then i realise i was looking at my forked repo
14:27 < sam_moore> Oh, just make sure you don't push anything to the git.ucc repo, because it doesn't go the other way
14:27 < sam_moore> Actuall I'll just remove everyone's keys to stop that from happening
14:28 < Callum__> haha, good to be sure. We need to make sure the other 2 have this sorted out. hopefully they rock up to the meeting tomorrow
14:28 < Callum__> oh wow. the logs go all the way back to when you first connected
14:28 < Callum__> haha
14:30 < Callum__> and according to me the logs were commited 15 hours ago
14:32 < sam_moore> Yeah, my logs will be the best to keep because I don't have to quit, so I should get everything
14:33 < Callum__> yea
14:34 < Callum__> Sigh. end of first week. already just written myself a fairly long list of things i need to do, which is by no means comprehensive
14:36 < sam_moore> I think I have a lot of work to do as well, I should do something for another unit
14:36 < sam_moore> See you later
14:36 < Callum__> later
15:32 < sam_moore> Ok, so pretty much anyone can comment on our stuff, and pretty much anyone can submit bug reports
15:32 < sam_moore> I'm going to say that's useful, and we should tell all the other teams about it
15:33 < sam_moore> Also I was supposed to go do something else, whoops
16:30 -!- james__ [[email protected]] has quit [Ping timeout]
18:35 < sam_moore> I changed my username because someone pointed out it sounds like "matches succ"
18:35 < sam_moore> But the old links should redirect
18:35 -!- justin_ [[email protected]] has joined #mctxuwa_softdev
18:36 -!- justin_ is now known as justin_kruger
18:37 -!- justin_kruger [[email protected]] has quit [EOF From client]
18:37 < sam_moore> Whoops
20:21 < Callum__> whoops?
21:20 < sam_moore> EOF From client
21:32 < sam_moore> I wonder how I can get people's forks to merge into the main repository without them having to issue a pull request
21:34 < sam_moore> Ah, I can't, because basically they have total control over their own fork
21:35 < sam_moore> Everyone just remember to fetch from upstream before you do work and issue a pull request when you are done, and hopefully things will stay relatively in sync.
21:50 -!- Callum__ [[email protected]] has quit [Ping timeout]
--- Day changed Mon Aug 05 2013
00:00 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
07:51 -!- james__ [[email protected]] has joined #mctxuwa_softdev
08:13 -!- james__ [[email protected]] has quit [Ping timeout]
10:29 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
10:33 -!- Callum_ [[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
11:01 -!- james__ [[email protected]] has joined #mctxuwa_softdev
11:19 -!- Callum [[email protected]] has joined #mctxuwa_softdev
11:19 < Callum> hallo
11:29 < sam_moore> Hi
11:30 < sam_moore> I've spoken to Omid from the electronics team, they are in charge of the "microcontroller"
11:31 < sam_moore> Apparently they think a raspberry pi is a good choice
11:31 < sam_moore> I told him we thought we might need a lower level device to do the ADC/DAC in particular
11:32 < sam_moore> But they seem to think a raspberry pi by itself will work
11:33 < sam_moore> I'm kind of not sure who's responsible for this part, since we have "server hardware" and they have "microcontroller" and the raspberry pi is sort of both
11:33 < sam_moore> But if we agree we want a raspberry pi it probably won't be an issue
11:33 < sam_moore> Also apparently the unit coordinators recommended the raspberry pi as well
11:34 < Callum> Yea he did
11:34 < james__> Well we are using the raspberry pi as a server
11:34 < james__> And we can bootstrap microcontrollers onto it
11:34 < james__> So i guess we are in charge of the pi
11:35 < james__> And the are in charge of the hardware around it
11:35 < james__> *they
11:35 < sam_moore> Seems logical
11:36 < sam_moore> I don't know if you get email notifications; I did a block diagram using the ideas from our first meeting
11:36 < sam_moore> I kind of added some thoughts of my own
11:38 < sam_moore> Hopefully it makes sense
11:41 < sam_moore> If either of you gets time, would you like to start typing some of the progress report?
11:51 -!- Callum [[email protected]] has quit [Ping timeout]
11:51 < james__> Do we have to submit a progress report?  Because the guide to mechatronics project work that was on lms said we had to do some things for week 1 but not that
11:52 < sam_moore> I'm pretty sure we do
11:52 < sam_moore> Hang on
11:53 < sam_moore> All teams are expected to report next monday (see the report format in the unit outline/overview).
11:53 < sam_moore> All teams must review their sub-system and provide high level detail of what is required.
11:54 < sam_moore>  All team must take an integrated approach. (I assume this means we have to start talking to other teams ASAP)
11:54 < sam_moore> I think the block diagram is a good start for the high level detail
11:54 < sam_moore> Then make some notes about how we're collaborating using git
11:55 < james__> git and irc
11:55 < sam_moore> We should decide whether Rowan or I will be the meeting convener
11:56 < james__> I think you
11:56 < james__> Just because you actually know what is going on
11:56 < sam_moore> Yes, I'm happy to do it and I think I can do a good job
11:56 < sam_moore> I just don't want to try and take over the group or something
11:56 < sam_moore> I have a good idea of what's going on, but we'll still need everyone to contribute
11:57 < sam_moore> I'm not a particular expert in any area, I just sort of know enough to have a general idea of how to approach things
11:57 < james__> Its important that the person who represents us has a firm knowledge base of whats possible and what we plan to do. Ultimately you are the person who best fills those requirements
11:58 < sam_moore> Ok, thanks, if everyone agrees we'll tell Rowan that when we meet
11:58 < sam_moore> And he can still talk to his friends for us, in fact the more of us that can communicate with the other teams the better
11:59 < james__> True
12:00 < james__> there isn't anything that says he can't talk to others
12:00 < sam_moore> Omid said his team was going to rotate the meeting convener, maybe we could try that later on once everyone has a better idea of what we're doing
12:00 < sam_moore> Anyway, I should do some other work, see you at 2pm
12:01 < james__> Yeah might be worth it.  Gives everyone a taster
12:01 < james__> okay see you then
14:45 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
15:00 -!- james__ [[email protected]] has quit [Ping timeout]
15:34 -!- justin_kruger [[email protected]] has quit [EOF From client]
18:26 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
20:38 < sam_moore> I'm going to try using the GitHub issues and milestones thing
20:39 < sam_moore> It might help with keeping track of what we need to do and what we've done
20:45 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
20:50 < sam_moore> I think we had some difficulty setting specific goals for this week
20:50 < sam_moore> I can try and put together some longer term goals as a start, if that's helpful
20:51 < sam_moore> Hmm
20:52 < sam_moore> We weren't given a lot of requirements that the guy was asking us about
21:06 < sam_moore> So the most important task seems to be "determine those requirements"
21:07 < sam_moore> Well, we talked about it in the meeting, but I'm going to make GitHub issues for each of the areas so we have a good record
21:32 < Callum__> Sam are you talking to yourself or am i not just seeing the other messages?
21:35 < sam_moore> Yeah, just ranting
21:36 < sam_moore> Well if you read the messages, then I was talking to you :P
21:37 < Callum__> haha just they seemed like they were structured like you were responding to someone
21:39 < sam_moore> I guess that's how I'm used to using IRC, people tend to say stuff broadly directed at anyone even though they won't get an immediate reply
21:39 < sam_moore> Or even if they don't need a reply
21:45 < Callum__> Fair enough
21:51 -!- justin_kruger [[email protected]] has quit [Ping timeout]
--- Day changed Tue Aug 06 2013
00:33 -!- Callum__ [[email protected]] has quit [EOF From client]
10:48 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
11:10 -!- james__ [[email protected]] has joined #mctxuwa_softdev
12:05 -!- james__ [[email protected]] has quit [Ping timeout]
12:28 -!- james__ [[email protected]] has joined #mctxuwa_softdev
12:57 -!- james__ [[email protected]] has quit [Ping timeout]
15:01 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
15:02 -!- justin_kruger [[email protected]] has quit [EOF From client]
15:12 < Callum__> Is the only image processing that needs doing detecting the edge of the can? (and doing measuring how it changes with time etc)
15:30 -!- james__ [[email protected]] has joined #mctxuwa_softdev
15:39 < Callum__> hey
15:39 < james__> what up
15:39 < sam_moore> Hi
15:39 < Callum__> Is the only image processing that needs doing detecting the edge of the can? (and doing measuring how it changes with time etc)
15:40 < sam_moore> Callum__: I think so
15:40 < james__> As far as i understand it yes
15:40 < Callum__> plus just booted up ubuntu on laptop. havent touched it since i did C programming a year ago xD
15:40 < sam_moore> It would also be nice to just have unprocessed images streamed to the GUI
15:40 < Callum__> yea what i was thinking
15:41 < Callum__> firstly, i can look into only processing a portion of the image, so we could get away with a larger resolution
15:41 < sam_moore> With the server side interface, I'm starting to think I'll ditch the apache2 webserver + CGI and integrate a minimal webserver + the lower level stuff into the same program
15:41 < Callum__> and openCV has a couple of algorithms to detect edges
15:41 < Callum__> so will likely look into one or 2 of those
15:41 < sam_moore> Just thinking about all the layers that are involved with the CGI approach... it probably won't turn out easier to code, and it will definitely be slower
15:42 < sam_moore> Plus, if we really care about performance, the apache2 webserver has a lot of features we don't care about
15:42 < james__> As long as i can access the raw files etc i should be able to display it via a gui
15:42 < sam_moore> The main one being it's designed to cope with multiple users well, and we want to configure it to only allow ONE user
15:43 < sam_moore> Yes, that sounds good
15:44 < Callum__> responding to who? me or james?
15:44 < sam_moore> Um... both now
15:44 < Callum__> haah
15:45 < sam_moore> Anyway, I've realised that our software will place an upper limit on the quality of the sensors
15:45 < james__> true
15:45 < sam_moore> Since we weren't given a requirement on quality, we should aim to get it as high as feasible
15:45 < sam_moore> But sensors group needs to have some idea of the upper limit that our software will place on quality
15:45 < Callum__> yea. 
15:46 < james__> Start simple and ramp it up until the hardware breaks?
15:46 < sam_moore> No point streaming 1000 images a second if the JavaScript GUI can't send requests that fast.
15:46 < sam_moore> Yep.
15:46 < sam_moore> I know you're supposed to do task break downs and all that time management stuff, but the fact is we need to experiment with actual code to work out the best implementation
15:47 < james__> yeah. break it down into code and test code?
15:48 < sam_moore> Maybe?
15:49 < sam_moore> Well, we've got a high level idea of the software
15:49 < sam_moore> The first tasks should be "decide on the best software implementation of each level"
15:49 < sam_moore> To do that we need to test some minimalistic implementations
15:50 < Callum__> yea
15:50 < sam_moore> So, to set a goal for week 2, can it be "Decide on software implementation at each point in the block diagram"
15:51 < sam_moore> And "Determine upper limit on data transfer rate through software systems"
15:51 < sam_moore> The second one might take a bit longer.
15:52 < Callum__> githubs down for maintenance. hahah
15:52 < sam_moore> That happened like 2 seconds after I submitted a comment on the CGI stuff
15:53 < sam_moore> For a while it was showing me a Unicorn (?)
15:53 < Callum__> yea i got that before
15:53 < Callum__> when trying to access on my laptop
15:53 < sam_moore> Well... we have the git.ucc server
15:54 < sam_moore> But I was starting to like the Issues and Comments and all those actual features
15:54 < Callum__> hmm. doubt it will be down for long. will have to see
16:10 < Callum__> back up
17:22 -!- james__ [[email protected]] has quit [Ping timeout]
18:09 -!- RowanHeinrich [[email protected]] has joined #mctxuwa_softdev
18:10 -!- RowanHeinrich [[email protected]] has quit [""]
18:34 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
18:35 < Rowan> test test
18:35 < Rowan> ??
18:43 < Callum__> Hey
18:56 -!- github [[email protected]] has joined #mctxuwa_softdev
18:56 -github:#mctxuwa_softdev- [MCTX3420] none pushed 2 new commits to master: http://git.io/ZDMvew
18:56 -github:#mctxuwa_softdev- MCTX3420/master 64b0cd9 Sam Moore: Investigate software for interfacing with hardware via HTTP requests...
18:56 -github:#mctxuwa_softdev- MCTX3420/master 5afaa23 Sam Moore: Merge branch 'master' of github:szmoore/MCTX3420
18:56 -!- github [[email protected]] has left #mctxuwa_softdev []
18:57 -!- github [[email protected]] has joined #mctxuwa_softdev
18:57 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/1nMEMA
18:57 -github:#mctxuwa_softdev- MCTX3420/master 9579cea Sam Moore: Makefile for webserver test...
18:57 -!- github [[email protected]] has left #mctxuwa_softdev []
19:41 -!- Rowan [[email protected]] has quit [Ping timeout]
23:09 -!- Callum__ [[email protected]] has quit [EOF From client]
23:21 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
23:21 -!- justin_kruger [[email protected]] has quit [EOF From client]
--- Day changed Wed Aug 07 2013
00:24 -!- github [[email protected]] has joined #mctxuwa_softdev
00:24 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/5DEPzw
00:24 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
00:24 -!- github [[email protected]] has left #mctxuwa_softdev []
00:52 -!- github [[email protected]] has joined #mctxuwa_softdev
00:52 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/r6aFJw
00:52 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
00:52 -!- github [[email protected]] has left #mctxuwa_softdev []
01:00 -!- github [[email protected]] has joined #mctxuwa_softdev
01:00 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/eZPWcQ
01:00 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
01:00 -!- github [[email protected]] has left #mctxuwa_softdev []
10:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
11:15 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
11:15 -!- justin_kruger [[email protected]] has quit [EOF From client]
19:36 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
20:43 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
20:45 -github:#mctxuwa_softdev- [MCTX3420] none pushed 3 new commits to master: http://git.io/Dhb-Fg
20:45 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
20:45 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
20:45 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
20:45 -github:#mctxuwa_softdev- [MCTX3420] none pushed 3 new commits to master: http://git.io/Dhb-Fg
20:45 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
20:45 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
20:45 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
20:46 < sam_moore> Whoops, I was trying to make it less spammy and ended up making it spam us
20:53 < Callum__> haha nice work
20:58 < sam_moore> I have a minimal web server in C done
20:58 < sam_moore> It was surprisingly easy actually
21:05 -github:#mctxuwa_softdev- [MCTX3420] none pushed 2 new commits to master: http://git.io/Tui0FA
21:05 -github:#mctxuwa_softdev- MCTX3420/master c1321a7 Sam Moore: Test webserver with minimalist JavaScript...
21:05 -github:#mctxuwa_softdev- MCTX3420/master 1b2939d Sam Moore: Merge branch 'master' of github:szmoore/MCTX3420...
21:07 < sam_moore> Hooray, more spam
21:07 < sam_moore> Maybe I should just turn that off.
21:35 < Callum__> Maybe, its kinda goods to know when people commit things though, restricted to one line would be good
23:23 -!- Callum__ [[email protected]] has quit [Ping timeout]
--- Day changed Thu Aug 08 2013
08:57 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
08:59 -!- Callum_ [[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
14:12 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
14:12 -!- justin_kruger [[email protected]] has quit [EOF From client]
--- Day changed Sun Aug 11 2013
11:18 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
12:57 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
13:55 -!- justin_kruger [[email protected]] has quit [EOF From client]
14:09 < Callum__> actually so much work to do already. 
14:47 < sam_moore> Yep
15:15 < Callum__> well iv spent some time thinking over this, finally get around to writing it down. so iv probably spent close to 4 hours or so thinking about it (while doing other things) but really only spent an hour and a half according to diary
15:25 < sam_moore> We can always flesh out people's reports with graphs and stuff
15:27 < Callum__> well we doing 1 per person or group?
15:29 < sam_moore> 1 per person is the safest way to go I think
15:29 < sam_moore> We can always summarise them
15:30 < Callum__> well, tbh i think we should do 1 per person and summarise, but not necessarily go for a full page. thing is not sure how they expect us to do 1 page for 5 people AND be detailed
15:30 < sam_moore> Yep
15:31 < Callum__> so they might end up making it 1 per person anyway. 
15:31 < Callum__> not very well thought out either way
15:31 < sam_moore> Let's just submit a multiple page report, with a bit from each person and a summary. If some people have less than a page that's fine.
15:32 < Callum__> Yea, agreed thats the best way to go about it. Unless they complain about it being too long
15:32 < sam_moore> That's why we include a summary :P
15:33 < sam_moore> Although, it might be difficult to make the summary actually summarise things, since everyone's already using pretty concise summaries
15:33 < sam_moore> Oh well, writing more stuff is safer to start with.
15:34 < Callum__> hmm. its kind of a pain though, write it all down in your book...oh look now i need to rewrite most of it for a report..
15:34 < sam_moore> Ah crap, I forgot about the book
15:34 < Callum__> haha
15:34 < sam_moore> Yeah... write it all down in the git commit messages, write it all down in the report, write it all down in the diary...
15:35 < sam_moore> I suppose in the "Real World" you have to do stuff like this
15:35 < Callum__> yea true 
18:16 < Callum__> Not sure when il get round to writing what i'v done but il do it tonight some time. We finalising it tomorrow and printing it off then?
18:27 < sam_moore> Yes, I'd like to have it done before the meeting, or at least do it first thing in the meeting
18:27 < sam_moore> Then there are some things I need to ask everyone about to progress with my part of the code
18:27 < sam_moore> Since I'm sort of doing the bit in the middle that gets all the other bits to talk to each other
18:28 < sam_moore> I think it would be good to keep all the raspberry pi code in a single process, running in seperate threads
18:29 < sam_moore> But to do that we'd need everyone to use the same language
18:30 < sam_moore> Also we need to start thinking about the structure of the system in a bit more detail
18:31 < sam_moore> Like: We can't just transfer data straight to a GUI, because the user will want to use the GUI to start the experiment, then go away and come back later to view results (and possibly save them on their own machine)
18:32 < sam_moore> Also if we do transfer everything straight to the GUI we'd be limited by the speed of the GUI, and JavaScript requests are slow
18:34 < Callum__> yea
18:34 < sam_moore> Pretty easy to just dump stuff to a data file, but we probably also want the ability to do it in realtime
18:35 < sam_moore> Anyway, good luck, see you tomorrow
18:36 < Callum__> Alright, cya tomorrow them
23:08 -!- Callum__ [[email protected]] has quit [EOF From client]
--- Day changed Mon Aug 12 2013
13:10 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
13:10 -!- justin_kruger [[email protected]] has quit [EOF From client]
--- Log closed Tue Aug 13 07:49:14 2013
--- Log opened Tue Aug 13 07:55:27 2013
07:55 -!- sam_moor1 [[email protected]] has joined #mctxuwa_softdev
07:55 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
07:55 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
07:59 -!- sam_moore [[email protected]] has quit [Ping timeout]
10:01 -!- Callum [[email protected]] has joined #mctxuwa_softdev
10:01 < Callum> So apparently we have a new member..
10:12 < sam_moor1> Yep, Jeremy Tan, apparently he's doing CS as well?
10:13 < sam_moor1> So, with the two sources of confusion we have so far...
10:13 < sam_moor1> 1. The Camera - Adrian thinks we need one, Sensors team doesn't, everyone needs to recheck calculations
10:14 < sam_moor1> The "Can" team wanted to use some kind of tiny can with a relatively thick wall, Adrian recommended a Coke Can, Oliver used Rockstar Cans last year and recommended them
10:14 < Callum> well, they may be right in saying we may not be able to do any proper processing on it
10:14 < Callum> but we will need one to relay whats actually HAPPENING in the system
10:14 < Callum> surely the sensors team see that..
10:15 < sam_moor1> I guess, I told them in their meeting it would probably be useful
10:15 < sam_moor1> Anyway...
10:15 < sam_moor1> We all got in trouble for not communicating between teams well enough
10:15 < sam_moor1> So now the 9am session is for teams to communicate (at least one member is meant to go)
10:15 < Callum> how many people went to the lecture?
10:15 < sam_moor1> About 6
10:16 < Callum> haha
10:16 < sam_moor1> I think only one team didn't have a representative, electronics?
10:16 < Callum> hmm. thats not too bad then. 
10:16 < Callum> but still, not really our fault communication was poor. we attempted to set up meetings and to convene with others.
10:17 < Callum> The only other thing we could have done is actually told people, right we're meeting at this time. come or dont (then you'd have like 1 or 2 people at most)
10:17 < sam_moor1> Yeah, I really think this project needed some kind of direction at the start
10:17 < sam_moor1> I think that's what we're going to have to do
10:18 < sam_moor1> We're going to have to be more assertive; we think we need Arduinos, electronics team doesn't seem to know, we should just say "Right, we're using some Arduinos"
10:18 < sam_moor1> At least that's the vibe I got from Adrian
10:18 < sam_moor1> Also what happened to my name
10:18 < Callum> hmm ok. it would help if we had the team convener meeting to do that
10:18 -!- You're now known as sam_moore
10:19 < Callum> and no idea
10:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
10:20 < sam_moore> Also, so far we've neglected physical details a bit
10:20 < sam_moore> Lastly, we need to start ordering things as soon as possible
10:21 < sam_moore> Oh, and we (as in, all teams) are supposed to have a schedule of tasks agreed upon
10:21 < sam_moore> Right, I need to have lunch
10:21 < sam_moore> *breakfast
10:22 < sam_moore> Then I guess I can panic some more
10:23 < Callum> haha. we'v only had 2 weeks to work on this really. We can pull it back.
10:24 < sam_moore> The scary part is where they do a very similar project every year and no one ever succeeds :S
10:25 < sam_moore> They seem to think simply throwing the entire class at it (instead of one team of 6) will make it work this time
10:25 < sam_moore> Oh well, they can't just fail the entire class
10:25 < sam_moore> It would be nice to actually succeed though
10:30 < Callum> Yea, well even if it doesnt work a lot of the marking will come from the shit like the diary
10:30 < Callum> but yes, it would be nice to see a can go boom
11:57 < Callum> alright so am i still doing the taking images thing and storing it? Coz we pretty much need the camera. what we do with the images though dno
11:58 < sam_moore> Just take the images and save them to a file for a start I guess
12:00 < Callum> alright. 
12:13 < Callum> I might reinstall linux on my laptop, stick with ubuntu or go debian?
12:51 < sam_moore> I'd recommend debian
12:51 < sam_moore> It's not that much harder to use, but it's closer to raspian
13:06 < Callum> alright. any port better to use?
13:15 < sam_moore> Oh, stick with "stable"
13:15 < sam_moore> ie: Wheezy
13:16 < sam_moore> No matter what you do, do NOT get "Sid"
13:18 < Callum> nah i meant the architecture
13:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:20 < jtanx> yallo
13:20 < Callum> hey
13:21 < sam_moore> Hi
13:23 < jtanx> i should say that right now I cant access g19 because I haven't gone through the safety induction yet
13:23 < sam_moore> Callum: The architecture shouldn't matter too much
13:24 < Callum> we can let you in. As long as you don't do anything stupid it will be fine 
13:24 < Callum> alright
13:25 < sam_moore> We can just compile code on the RPi itself, or if that's too slow (I doubt it) there will be cross compilers
13:25 < Callum> true
13:25 < sam_moore> It's just nice to be able to run test software in debian
13:25 < jtanx> so do you have access to an/the RPi and the other microcontrollers, or is that tba
13:26 < sam_moore> We have access to "an" (not "the") RPi
13:26 < Callum> rowan has an arduino too
13:26 < sam_moore> Ah, that's good
13:26 < Callum> atleast i think he said he did
13:27 < Callum> just dont know the exact hardware we're using and won't get access to it for a few weeks atleast (hopefully not too long. need to make sure other teams are doing everything on time)
13:27 < Callum> speaking of which we should write up a time schedule for our team and make sure a project one gets written up
13:27 < sam_moore> Adrian said to allow for 6 weeks ordering time
13:28 < sam_moore> Yeah, the entire class needs to agree on a schedule
13:28 < Callum> hmm. true i guess, by the time adrian gets the bill of materials, clears it and the stuff gets ordered in
13:28 < Callum> but at the current rate shit wont be chosen in time
13:29 < jtanx> i'm surprised that not much has been done in three weeks
13:29 < sam_moore> The problem is there are too many people working on this
13:29 < Callum> its been less than 3 weeks though
13:30 < sam_moore> Right. Let's make a schedule then.
13:30 < sam_moore> Just a second
13:30 < Callum> we only got the teams on like wed first week
13:30 < jtanx> ok
13:31 < Callum> And having 5-6 people per team across 6 teams without a project manager...makes sense
13:31 < sam_moore> Haha
13:31 < sam_moore> Ok, so I have an excel document
13:31 < sam_moore> Anyone here actually made a schedule for a project?
13:32 < jtanx> nope
13:32 < sam_moore> Welp
13:32 < jtanx> ms project was suggested in cits3200
13:32 < jtanx> nice gantt chart and everything
13:32 < sam_moore> Does it allow collaborative editing?
13:33 < sam_moore> Also, is there an open source version :P
13:33 < sam_moore> Ok, I've shared a google spreadsheet
13:34 < jtanx> not likely haha although there was something called ms project server which might allow collaboraitve stuff
13:34 < jtanx> you can get this all off msdnaa
13:34 < jtanx> but since noone's used it before it might be better to stick with excel
13:34 < sam_moore> Ok, let's just try and think what we need to get other teams to do, and what we need to do for other teams
13:35 < Callum> HAHAH
13:35 < sam_moore> Well
13:35 < Callum> Hello everyone,
13:35 < Callum> It appears that the lab signup sheets for GENG4402, the MECH/MCTX/Oil and Gas students have dissapeared from the desk at the stairwell.
13:35 < Callum> Can you please check if you have it and return it as soon as possible? Many students still need to sign up. I will then scan and put online once complete so that you can check when your lab is.
13:35 < Callum> PLEASE RETURN THE SHEETS.
13:35 < Callum> Thank you
13:35 < Callum> thats hilarious
13:35 < jtanx> ~~
13:36 < sam_moore> Oh dear
13:36 < sam_moore> It strikes me that something like a Makefile, except a bit more GUI, would be good for this
13:37 < jtanx> wait
13:37 < jtanx> you lost me there - what are you referring to
13:37 < Callum> ^
13:37 < sam_moore> To compile C projects that involve several files, you use something called "make"
13:37 < sam_moore> You write a Makefile for it
13:37 < jtanx> yah
13:38 < sam_moore> The Makefile has a list of targets and what they depend on
13:38 < sam_moore> And how to make them once their dependency exists
13:38 < jtanx> ok
13:38 < sam_moore> Then you run "make" and it reads the make file and magically compiles everything in the right order
13:38 < Callum> yea we get what make is
13:39 < sam_moore> Ok, I was referring to the list of tasks
13:39 < sam_moore> That depend on each other
13:39 < jtanx> ook
13:39 < jtanx> well
13:39 < sam_moore> It was a bad joke
13:39 < sam_moore> I am not seriously suggesting we use make to plan the project
13:40 < Callum> hahahah
13:40 < Callum> now that i would like to see :p
13:40 < jtanx> um just with git
13:40 < jtanx> i've never done pull requests before
13:40 < sam_moore> Neither had we until last week :P
13:41 < sam_moore> Basically you make your own fork of the repositoy, and there is a pull request button that lets you ask to have the changes merged back into the upstream repository
13:42 < jtanx> ahh
13:42 < jtanx> ok
13:51 < jtanx> well that was pretty straight forward - I understand it now
15:06 < sam_moore> I made a #mctxuwa channel for group representatives
15:06 < sam_moore> I don't know if people will use it, but at least it's an attempt at something
15:47 < Callum> tbh it makes more sense for us all to use one
15:47 < Callum> unless the one for everyone is actually used often enough to justify us having our own
16:11 < sam_moore> Yeah, there's nothing stopping people that aren't group representatives from joining it
16:11 < sam_moore> It will certainly make it easier if there are more people talking to other teams directly than just the representative
16:11 < sam_moore> We might still want our own for discussing the details of code
16:12 < sam_moore> Speaking of which, I'm currently tidying up the test webserver code I wrote
16:17 < sam_moore> Does: FunctionName, variable_name, Structure, Extern_FunctionName, g_global_variable seem suitable
16:19 < sam_moore> Well, unless anyone objects before I've satisfied my obsessive compulsive urges, that's what it will be
16:19 < sam_moore> Until then, it'll probably take a while, and find-replace is fast
16:20 < sam_moore> Other than that, the style of comments/documentation in the test webserver is what I'll keep using
16:22 < sam_moore> If someone wants to actually write code... it would be good to have a watchdog program that uses exec to start the main program and detects SIGCHLD when it crashes
16:22 < sam_moore> Then we can put some kind of emergency "Turn all the things off!" in that
16:57 < jtanx> what about something like this? http://stackoverflow.com/questions/696839/how-do-i-write-a-bash-script-to-restart-a-process-if-it-dies
16:58 < sam_moore> Oh cool, that looks good
17:03 < sam_moore> I'll be back later tonight, bye
17:21 < jtanx> umm
17:21 < jtanx> wow okay you're actually writing a webserver from the ground up?
17:22 < jtanx> what if you just had software that got the results and then wrote that to a html/php file
17:22 < jtanx> then you can just run nginx and serve it up
17:45 < jtanx> or what about if you ran an sql server, so you update the database from your program
17:46 < jtanx> then you can either use php to interface with the database
17:46 < jtanx> or you could make some sort of api and serve the data in json format
17:50 < jtanx> sqlite
19:12 < jtanx> you could do something like this: http://pastebin.com/mEdbu4jR
19:13 < jtanx> where instead of outputting html, you could make it output json, which is then interpreted by your actual webpage
20:44 -!- Callum [[email protected]] has quit [Ping timeout]
20:49 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
20:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Wed Aug 14 2013
07:58 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:13 < jtanx> I've done a version using fastcgi, which was surprisingly quite easy to set up
09:13 < jtanx> see here: https://github.com/jtanx/MCTX3420/tree/master/testing/fastcgi-approach
10:41 < sam_moore> That looks interesting, I'd prefer that to the PHP/database solution
10:42 < sam_moore> My concern is: You have to query the web server to start the process, even though it keeps running
10:42 < sam_moore> Also, I know "write a custom HTTP server" sounds scary, but it does actually work
10:43 < jtanx> nah
10:43 < jtanx> fastcgi
10:43 < jtanx> the process is started once and always runs
10:43 < jtanx> so you have a request loop
10:44 < jtanx> wait
10:44 < jtanx> how do you envision it working?
10:45 < sam_moore> Oh, right, I see how the fastcgi approach would work, it's basically the same idea; you have something responding to HTTP queries in one thread, something dealing with sensors/actuators in seperate threads
10:45 < jtanx> yeah
10:46 < jtanx> except that you don't have to worry about maintaining your own webserver
10:46 < sam_moore> Cool
10:46 < sam_moore> I do think that the HTTP server isn't that hard, and it's mostly working
10:46 < sam_moore> But we can probably switch to fastcgi
10:48 < sam_moore> I mean, we still have to parse a query string right?
10:48 < jtanx> well yes
10:48 < jtanx> if your request was
10:48 < jtanx> http://blah/cgi/?key=value&anotherkey=value2
10:48 < jtanx> you'd get back key=value&anotherkey=value2
10:48 < jtanx> as query string
10:50 < jtanx> try it out here: http://124.169.120.181:8080/cgi
10:51 < jtanx> (hopefully that forwards ok)
10:51 < sam_moore> Yep, that's cool
10:51 < sam_moore> The HTTP server I wrote basically does that
10:51 < sam_moore> But if it really bothers you, I'm fine with switching to fastcgi :P
10:52 < jtanx> well whatever works
10:52 < jtanx> but I thought it might be more maintainable if you used something that already exists :P
10:52 < sam_moore> Yeah, but thinking about it, what maintainence does the HTTP server require?
10:53 < sam_moore> Oh well, it's a good idea
10:53 < jtanx> for this situation not much
10:57 < sam_moore> We can pretty easily start with a structure that would allow us to switch, but I'd lean towards keeping the custom HTTP server
10:58 < sam_moore> Have you done multithreading in C before?
10:58 < jtanx> in windows yes
10:58 < jtanx> on linux not really
10:58 < sam_moore> Ah, I've only done it on linux
10:58 < jtanx> i did a bit in operating systems
10:59 < jtanx> but kinda forgot
10:59 < sam_moore> It shouldn't be too hard for our purposes
11:00 < jtanx> that thing with running a custom webserver is that if anyone wants to reuse this in the future, i doubt they'd really like the idea of that
11:01 < jtanx> say they had some new fangled thing that requires php
11:01 < jtanx> which isn't going to work 
11:01 < jtanx> but with a standard webserver like apache or nginx, it's really easy to just install an extra addon
11:02 < sam_moore> I suppose... what would they need the new fangled php thing for?
11:03 < jtanx> well that's the thing - for now I don't know, but it could be required
11:03 < sam_moore> Yeah, good point
11:03 < sam_moore> Ok, another reason to use an existing web server, is we might require some advanced features if we want to be serious about the safety stuff
11:04 < sam_moore> For example, it would be a fair amount of work to add SSL to make the custom thing do https
11:04 < jtanx> oh yeah
11:04 < jtanx> that too
11:04 < sam_moore> Also we might want some authentication on it
11:04 < jtanx> nginx/apache are highly customisable
11:05 < sam_moore> I've never used nginx, what are it'
11:05 < sam_moore> s advantages over apache2?
11:05 < jtanx> nginx
11:05 < jtanx> yup
11:05 < jtanx> its really good
11:05 < sam_moore> Haha
11:05 < jtanx> a lot of sites use it because it's fast
11:05 < sam_moore> Fast is good
11:05 < jtanx> faster than apache
11:05 < sam_moore> Sold
11:05 < sam_moore> Well, we only need one user as well
11:05 < sam_moore> In fact, we deliberately do not want to have multiple clients able to use the thing at the same time
11:05 < jtanx> haha true
11:07 < sam_moore> Ok, so I think you've convinced me to use fastcgi
11:07 < sam_moore> Most of the custom HTTP server was reused code, so I didn't waste too much time on it
11:07 < jtanx> haha ok
11:07 < jtanx> have you written one before?
11:09 < sam_moore> Not specifically a HTTP server, but I've written a project for posix systems with a fair bit of networking
11:09 < sam_moore> git.ucc.asn.au/?p=matches/swarm.git
11:10 < jtanx> nice
11:10 < sam_moore> It allows you to run a shell, eg: bash accross multiple machines at once
11:11 < sam_moore> Not as useful as I thought it might be, but it was fun
11:12 < jtanx> heh
11:12 < jtanx> what did you end up using it for?
11:13 < sam_moore> I was setting up a programming competition where you have AIs play against each other
11:13 < sam_moore> I wanted to make a round robin
11:13 < sam_moore> So I had a bash script setup to do that, but then I got impatient, because it would have to run the games in order
11:14 < jtanx> oO
11:14 < sam_moore> Well it turned out no one entered the competition, so I probably didn't need to go overboard
11:14 < sam_moore> But maybe I can use it for something else
11:15 < sam_moore> For the threading I'm thinking of using pthreads
11:16 < sam_moore> The alternative is OpenMP, but it's more suited to numerical computation, rather than having seperate things talking to each other
11:16 < jtanx> okay
11:17 < sam_moore> My goal for this week was to have the framework started, so we just have some really basic threads running and then we can start implementing them
11:17 < jtanx> yeah that would be good
11:18 < sam_moore> If you want to do some work with the fastcgi part so that we'll be able to parse the query strings, that would probably be a good start
11:18 < sam_moore> We don't have the exact details of pretty much anything yet
11:18 < sam_moore> Maybe talk to James/Rowan about how the GUI is going to query the server
11:19 < sam_moore> Also, did you see my suggested naming convention?
11:19 < jtanx> no
11:20 < sam_moore> I don't really mind, although I'd prefer not to have hungarian notation
11:20 < sam_moore> As long as it'
11:20 < sam_moore> s consistent
11:21 < sam_moore> But the suggestion was: FunctionName, variable_name (local or member), Structure, ENUMVALUE, Extern_FunctionName, g_global
11:21 < jtanx> okay I'll try to keep to that
11:22 < sam_moore> Cool, I should probably go do something else
12:33 < jtanx> i gotta go
12:33 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
15:39 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:22 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
16:23 -!- justin_kruger [[email protected]] has quit [EOF From client]
16:43 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
16:56 < jtanx_> a beagleboard
16:56 < jtanx_> hmm
16:58 -!- jtanx [[email protected]] has quit [Ping timeout]
16:58 -!- jtanx_ is now known as jtanx
17:03 < jtanx> is it the beaglebone black?
17:03 < jtanx> sounds interesting
17:04 < sam_moore> They didn't specify
17:04 < sam_moore> Oh right, I accidentally cut out his message
17:04 < sam_moore> tl;dr "Beagle Board"
17:04 < jtanx> the beagle board is around $125 though
17:04 < sam_moore> Probably the Beaglebone black
17:04 < sam_moore> Oh really
17:04 < sam_moore> Heh
17:04 < jtanx> yeah
17:05 < jtanx> the beaglebone black is $45
17:05 < jtanx> but just looking the A/D converter on the black has a max voltage of 1.8v
17:05 < sam_moore> That's probably what they meant, since they said it is "not much more expensive"
17:05 < sam_moore> That should be fine; the sensors team says things are in mV
17:05 < jtanx> okay
17:05 < jtanx> that's good
17:05 < sam_moore> Really though... electronics should be asking the sensors team stuff like this
17:06 < jtanx> heh yeah
17:06 < sam_moore> They should probably have asked us if it was feasable for software
17:06 < sam_moore> Maybe they had someone who knew it would be, but still
17:06 < sam_moore> It looks like it is anyway, so crisis averted
17:07 < jtanx> just with the sensors, I think that the diferences need to be amplified so it covers the full range of the A/D converter
17:07 < sam_moore> Yes, the sensors guy knows that
17:07 < jtanx> yeah so if its only 1.8v there's less range than 0-5v
17:08 < jtanx> is that compensated enough by having a 12 bit a/d converter vs a 10 bit (i think arduino is 10 bit) converter
17:10 < sam_moore> I think so; you get ~4x more resolution from the 12 bit ADC and lose ~3x from the lower range
17:10 < sam_moore> Also there's no set requirement yet on what the resolution should be
17:11 < jtanx> true
17:11 < jtanx> well in any case the bb black sounds quite nice
17:11 < sam_moore> Yep, it'll probably be good to use
17:14 < sam_moore> I'm much happier now that we actually have regular verbal communication with the other teams
18:23 < sam_moore> I'm looking into getting doxygen working for this
18:59 < jtanx> for the documentation?
18:59 < jtanx> seems good, but never used it before myself
19:01 < jtanx> looks a lot like javadoc
21:26 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
21:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:54 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Thu Aug 15 2013
01:20 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
01:20 -!- justin_kruger [[email protected]] has quit [EOF From client]
07:58 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:21 < jtanx> hey
08:22 < jtanx> just a suggestion for the logging functions, but you can use macros
08:22 < jtanx> to get the function name (and even file name)
08:22 < jtanx> v
08:22 < jtanx> http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
08:23 < jtanx> so you can do stuff like #define Log(level, fmt, ...) LogReal(level, __func__, fmt, __VA_ARGS__)
08:25 < jtanx> it should be c99 conformant
09:15 < jtanx> I created a pull request anyway
09:33 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
13:33 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:39 < sam_moore> Yeah, I probably should have looked at that
13:46 < jtanx> back to the rpi+arduino
13:47 < jtanx> didn't they know about the beagle board black, or can that not be used for some reason?
13:48 < jtanx> beagle bone* black
14:20 < sam_moore> I don't know what model they were looking at exactly
14:20 < sam_moore> I told them the Beagle Bone was about $50, I haven't had much time to research it myself
14:20 < sam_moore> I didn't know about the Beagle Board/Bone, which was why I suggeste the RPi + Arduino
14:20 < sam_moore> They originally were just considering an Arduino
14:21 < sam_moore> Which would not have been fun for the remote interfacing stuff
14:21 < sam_moore> Well we could do it, but we wouldn't be able to have a nice web browser controlled GUI, probably some dedicated networked server/client with a GUI program installed on the client machine
14:22 < sam_moore> Also image processing would have been interesting
14:23 < sam_moore> Next time there's a combined groups meeting, hopefully we can talk to them more
14:24 < jtanx> yeah
14:24 < jtanx> there's quite a few
14:24 < jtanx> there's a beagleboard which is ~150
14:24 < jtanx> beaglebone which is ~90
14:24 < jtanx> beaglebone black which is ~50
14:24 < sam_moore> Right
14:24 < sam_moore> So they were probably looking at the beaglebone for $90
14:24 < jtanx> yeah probably
14:24 < jtanx> it's weird because the black version has better specs, from what i can see
14:25 < sam_moore> But still, even for $150, if it saves us 10 hours of writing code to interface the RPi with Arduinos, it will be worth it
14:25 < jtanx> yeah exactly
14:25 < sam_moore> Arduinos themselves cost a bit
14:25 < jtanx> well
14:25 < jtanx> you can get equivalents off ebay
14:25 < jtanx> like an uno is $10
14:26 < sam_moore> The only issue with the beaglebone to avoid having to use arduinos as well, is whether it has enough ADC by itself
14:26 < jtanx> yeah
14:26 < jtanx> well how many sensors are needed
14:26 < sam_moore> If it doesn't, you might have to add an Arduino or two anyway
14:26 < jtanx> you could just add on an adc chip
14:26 < sam_moore> Yes, or something like that
14:27 < jtanx> the beaglebone has like a bazillion gpio ports
14:31 < sam_moore> Well without getting into the specific details, it sounds like we should recommend they use that
14:32 < sam_moore> Apparently the sensors team will have a list ready by monday, which will be good
14:33 < jtanx> that'd be good
14:35 < jtanx> when are combined group meetings? just the 9am slot? 
14:36 < sam_moore> 9am Tuesday is the "official" time picked by Adrian, 2pm Wednesday is the time that we agreed between the teams
14:36 < sam_moore> I'm going to go to both, if more people want to come from the team that's also good
14:37 < sam_moore> Realistically not everyone is going to come, so I'll have to send emails a lot
14:38 < jtanx> ok
14:39 < sam_moore> What account do you need to be invited to the dropbox?
14:39 < sam_moore> I think Alex invited everyone using their student email
14:40 < sam_moore> Oh right, you wouldn't have been in the list that he used if you enrolled late
14:40 < jtanx> yeah, through student email would be good
14:41 < jtanx> last year's experiment ran with an arduino diecimila which only had 5 analogue inputs
14:41 < jtanx> any reason why we need more?
14:41 < jtanx> sorry that's 6
14:42 < sam_moore> I think the estimate was: 4-6 strain gauges, 1 temperature sensor, 1 microphone, 2 pressure gauges, 1 (maybe 2) USB webcam
14:43 < jtanx> ok
14:44 < jtanx> At that rate you would definitely need something with more analogue inputs
14:45 < sam_moore> We also might need a DAC for one of the pneumatics team's devices
14:46 < sam_moore> But you can't get that on a microcontroller, there'd have to be a seperate module
14:46 < jtanx> yep
14:48 < jtanx> it'd be no point interfacing an arduino to the rpi/beaglebone if all you want is more analog inputs
14:49 < sam_moore> If you can get modules for ADC that can talk to a rpi/beaglebone, then yes
14:49 < jtanx> yeah
14:49 < jtanx> I don't think they're too hard to wire up
14:50 < sam_moore> I think the electronics team should be considering all this, but I don't know since we haven't verbally spoken
14:50 < sam_moore> Well not at length anyway
14:51 < sam_moore> Just when I happen to bump into Omid
14:51 < jtanx> hmm
14:54 < sam_moore> This project is probably going to be a good lesson in "Why you need a project manager"
14:55 < jtanx> so true
14:59 < jtanx> with the web interface, what sort of update times are we looking at?
15:00 < sam_moore> My tests with apache2 and the custom HTTP server showed it took about 50us for jQuery to get an AJAX request
15:01 < sam_moore> There was only one data point returned each time though, we can probably optimise it a bit by returning multiple data points with a request
15:01 < jtanx> yeah
15:07 < jtanx> I wonder what sort of performance impact running one (or two) cameras would have on the rpi/beaglebone
15:44 < jtanx> urgh
15:45 < jtanx> I was wondering why my nginx config wasn't working
15:45 < jtanx> until I realised that gedit was creating a backup copy of the config file
15:45 < jtanx> so nginx was reading both the original and backup
17:28 < sam_moore> That's wierd, you'd think it would only read one config file
17:34 < jtanx> well it was in a config directory
17:36 < sam_moore> Oh, ok
18:49 < jtanx> so the current idea i have with the web thing is
18:49 < jtanx> you can query it like http://domain/api/module?key=value&key=value2
18:50 < jtanx> and then you could return something in json format or whatever is most suitable for the ajax query
19:46 < jtanx> you can test it at http://mctx.us.to:8080/apoi
19:46 < jtanx> woops, http://mctx.us.to:8080/api
19:46 < jtanx> the only 'module' which will give a response of '200 OK' is sensors
19:47 < jtanx> which currently spits back any arguments you pass to it
19:47 < jtanx> eg http://mctx.us.to:8080/api/sensors?k=v
19:50 < jtanx> hopefully it doesn't break
20:44 < sam_moore> I'll take a look
20:45 < sam_moore> Looks good
20:45 < sam_moore> I'm writing a dummy thread for a sensor now
21:04 < jtanx> the code behind it (in the cgi module) is a bit clunky right now though
21:04 < jtanx> is there a meeting tomorrow?
21:05 < sam_moore> I don't think so, sorry
21:06 < jtanx> ok that's alright
21:06 < sam_moore> Things aren't urgent (yet)
21:07 < jtanx> heh
21:12 < sam_moore> For the progress report: I'd like everyone to write a page individually, then we can summarize those in the group report
21:12 < sam_moore> Well you don't have to write a whole page, and if you miss a week or so it's not a big problem
21:16 < jtanx> ok
21:17 < jtanx> i'll try to remember that
21:18 < jtanx> do you think we need to keep track of how long we spend on this project
21:18 < jtanx> for that 'cost estimate'
21:28 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
21:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:23 < sam_moore> For the cost estimate: Yes, we are supposed to have a technical diary (hand written)
22:23 < sam_moore> Including all notes and times worked on the project
22:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Fri Aug 16 2013
08:00 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:48 < jtanx> I was wondering what sort of model you have for reading/storing sensor values and controlling actuators
10:02 < sam_moore> At the moment each sensor has a thread that continuously polls the sensor and dumps data to a binary file
10:03 < sam_moore> For reading there is a thread that fills a buffer from the file when it gets a request
10:04 < sam_moore> It might be better to change to a single thread for sensors/actuators though
10:04 < jtanx> yeah, I was about to say if it was necessary to have one for each
10:05 < sam_moore> Probably not, if you had varying polling speeds it would be useful, because you could poll the fast sensors seperately from the slow ones
10:05 < jtanx> how do you wish to pass the data to the fcgi module?
10:06 < jtanx> right now
10:06 < jtanx> i've kinda set it so
10:06 < jtanx> there's this thing called a ModuleHandler
10:07 < jtanx> so you can pass it some data (tba what this is), and it also receives the query string from the use
10:09 < sam_moore> Well, the ModuleHandler gets called whenever the right HTTP request is made right?
10:10 < sam_moore> So, that function retrieves the data it needs to respond to the request
10:10 < jtanx> well rightnow the typedef is
10:10 < jtanx> typedef void (*ModuleHandler) (Data *data, char *params);
10:10 < jtanx> so it's up to you to write a module handler (eg SensorsHandler)
10:11 < sam_moore> Ok, data's a bit of an ambigous name, so is that something passed to the ModuleHandler when the FastCGI gets a request?
10:11 < jtanx> well the data thing was a placeholder for whatever sensors/actuators data there was
10:11 < sam_moore> Is it meant to be sensor data, or is it a value that the user has passed through HTTP
10:11 < jtanx> the query string is part of params
10:11 < sam_moore> Ok, right, that makes more sense
10:12 < sam_moore> My view had the ModuleHandler getting the appropriate data itself
10:12 < jtanx> Ok
10:12 < sam_moore> Given the params
10:13 < jtanx> I'm just not really used to using global variables
10:13 < sam_moore> The global sensors array?
10:13 < jtanx> yeah
10:13 < jtanx> i take it that's where you access data from?
10:14 < sam_moore> Yes
10:14 < jtanx> oh yeah one more thing, when you get a request, should it only return the latest data?
10:20 < sam_moore> We should probably think some more about this as a whole group
10:20 < sam_moore> So, you have a sensor that can (probably) poll a lot faster than you get requests via jQuery
10:21 < sam_moore> You can write it so that you only actually query the sensor when you get a request, but then you're wasting the chance to get data that could be useful
10:22 < sam_moore> Or you can have it so that the sensor is continuously polling (What my code is simulating at the moment)
10:22 < sam_moore> With the continuosuly polling sensor; when you get a request, you can either return the most recent block of data you got
10:23 < sam_moore> Or you can have it so that the data will be sent in sequential order (which is what my code currently does)
10:23 < jtanx> hmm
10:23 < sam_moore> I'm pretty sure continously polling is better than querying each time you get a request, since after all this is an experiment and you want the data
10:23 < jtanx> yeah
10:24 < jtanx> I agree with you there
10:24 < jtanx> so you're saying, continuously poll and log the results
10:24 < jtanx> and when a request comes in, send back all the data up to the point when the last request came in
10:25 < sam_moore> Well that's what the server program I wrote simulates at the moment.
10:25 < sam_moore> However it might be more sensible for the request to just get the most recent data.
10:25 < jtanx> hmm
10:25 < sam_moore> Ah, yeah that's probably better actually
10:25 < jtanx> then you're logging more points than youdisplay
10:26 < sam_moore> Yes, but you can always add a function to pull all the data points and save to a csv or something like that.
10:26 < sam_moore> In fact I think we'd want to do that.
10:27 < jtanx> yeah ok
10:27 < jtanx> that sounds not too bad
10:27 < jtanx> but if that's the case
10:27 < sam_moore> If you actually use this for an experiment, you're not going to want to have to do all your analysis in a JavaScript GUI
10:27 < jtanx> true
10:27 < sam_moore> The GUI is for getting live information on the state of the system more than for data analysis
10:27 < jtanx> but if that's the case you might want to allow direct access to the latest dataset
10:28 < jtanx> instead of having to read from the file
10:28 < jtanx> if that's possible
10:28 < jtanx> then you can directly record the results in csv format
10:28 < sam_moore> Yes, I thought about that; you can have a buffer of points accessed by the request thread easily enough
10:29 < sam_moore> There are some difficulties though with managing the buffer
10:30 < sam_moore> Wait, maybe it's easier than I though
10:30 < sam_moore> Yeah, the reason I started saving stuff to a binary file was because I was thinking of the requests having to get the data in sequence
10:32 < sam_moore> I have some other stuff to do today unfortunately
10:33 < sam_moore> I have a feeling it won't be trivial to just access the most recent dataset, I'll have to think about it
10:34 < sam_moore> However, currently it should be easy to change so that the request gets data from the end of the binary file, rather than keeping track of its position
10:34 < sam_moore> The function QuerySensor is what I was thinking the SensorHandler would do to get data; it just fills a buffer and prints it at the moment
10:35 < sam_moore> Binary file access is pretty fast, we could even just keep the binary file and change the data to csv when it goes to the client
10:36 < jtanx> ok, I'll keep that in mind
11:11 < sam_moore> Oh, you can replace the Data* pointer with a Sensor* pointer and then not have to use the global variable directly, that's probably best
11:13 < jtanx> well it might not only be sensor data
11:13 < jtanx> it could be actuator stuff or anything else
11:13 < sam_moore> I suppose
11:14 < jtanx> maybe I should change the typedef to void*
11:14 < jtanx> then you can cast it to whatever
11:14 < sam_moore> Yeah, that will work
11:15 < sam_moore> Actuator stuff is going to be a bit of a seperate (hopefully easier) problem
11:15 < sam_moore> In that case you can just wait for a query before doing anything
11:15 < sam_moore> Anyway, I've distracted myself again, this is just too interesting :S
11:15 < jtanx> hahaha
11:16 < jtanx> anycase for the actuator you would have a separate handler function
11:16 < sam_moore> Yes
11:16 < jtanx> eg ActuatorHandler
11:20 < jtanx> fcgi is pretty whack
11:20 < jtanx> it replaces printf
11:21 < jtanx> so when you printf (or fwrite for binary?), that gets sent to the client
12:03 < jtanx> hey
12:04 < jtanx> what if we stored stuff in an sqlite library
12:04 < jtanx> sorry database
12:04 < jtanx> on second thoughts nah
14:58 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
15:01 -!- jtanx [[email protected]] has quit [Ping timeout]
15:02 -!- jtanx_ is now known as jtanx
15:11 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
15:18 -!- jtanx [[email protected]] has quit [Ping timeout]
18:59 -!- jtanx_ is now known as jtanx
21:28 < sam_moore> So, I did a bit of testing with sqlite vs a binary file
21:28 < sam_moore> sqlite takes about 1000x as long for saving data
21:28 < sam_moore> I haven't tested reading it back yet
21:28 < sam_moore> But more worrying
21:28 < sam_moore> I get a segmentation fault using sqlite
21:29 < sam_moore> And it's in the sqlite library somewhere; not my test code
21:29 < sam_moore> Running sqlite in valgrind shows a bunch of complaints about uninitialised values
21:29 < sam_moore> So... I'd recommend we just use a binary file
21:30 < sam_moore> A database is good for storing more complex data, but when you just need to store data recorded in a sequence, it's probably unnecessary
21:36 < jtanx> yeah sqlite not so good for file performance
21:36 < jtanx> because every insert it has to confirm the write to disk
21:36 < jtanx> the segfault
21:36 < jtanx> may actually be because you didn't initialse the mutex
21:36 < jtanx> es
21:36 < jtanx> i tried compiling it on mingw and it segfaults on the mutex unlock
21:37 < sam_moore> Re: fcgi replacing printf - It probably calls dup2 to change stdout from the terminal to a domain socket or fifo that nginx listens to
21:37 < jtanx> nah 
21:38 < jtanx> fcgi_stdio just has a bunch of defines
21:38 < sam_moore> Oh really, that's wierd
21:38 < jtanx> so printf becomes FCGI_printf
21:38 < jtanx> so fcgi_stdio must be the first include in the fcgi module
21:38 < sam_moore> I would have thought it was simpler to just change stdout than replace the whole printf function
21:38 < sam_moore> But whatever, we're not implementing fcgi :P
21:38 < jtanx> haha
21:39 < sam_moore> Oh, the mutex needs initialising, yeah
21:39 < sam_moore> But the test I did was just a serial program, no mutex
21:39 < jtanx> ah
21:39 < jtanx> well
21:39 < sam_moore> We'll be using gcc to compile on the beaglebone/rpi
21:40 < sam_moore> I think some implementations of pthreads need an initialiser but others don't, I'll have to check
21:40 < sam_moore> But pthread_mutex_init doesn't show up in man pages on debian
21:40 < jtanx> yeah it's not on ubuntu either
21:41 < jtanx> have you ever worked with clang
21:42 < sam_moore> No
21:42 < jtanx> neither but it seems pretty cool
21:45 < jtanx> when you compile it gives better diagnostic output when something goes wrong
21:46 < jtanx> it's a drop in replacement for gcc
21:47 < sam_moore> Interesting
21:51 -!- jtanx [[email protected]] has quit ["brb"]
21:55 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:57 < jtanx> if you kept the file handles for the sensor data always open
21:58 < jtanx> and immediately wrote to them when a data point is polled 
21:58 < jtanx> is there much performance difference to buffering first?
22:05 < sam_moore> Yeah, it's probably better to keep the file handles always open
22:05 < sam_moore> The operating system will use some kind of buffer for the file anyway
22:06 < sam_moore> I've got some basic programs, maybe I'll make some performance graphs tomorrow
22:07 < sam_moore> On the other hand, I need to do some of the meta stuff (list of tasks that need to be completed, etc) before Monday
22:08 < sam_moore> I should look into a #define or something to initialise the mutexes if they need to be
22:09 < sam_moore> Anyway, I need to sleep
22:11 < sam_moore> I wonder how James and Callum are going, they haven't been in the channel for a while
22:12 < jtanx> yeah, it's pretty quiet
22:17 < sam_moore> If we can get a second meeting in the week, preferably a longer one that would be good
22:18 < sam_moore> Particularly if we can start working on code at the same time
22:18 < sam_moore> But we'll see
22:18 < sam_moore> Everyone has other stuff to do after all
22:18 < sam_moore> I'm spending way too much time on this unit compared to my others
22:18 < sam_moore> Then again this unit will probably require the most work
22:19 < sam_moore> Anyway, bye
22:23 < jtanx> bye
22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Sat Aug 17 2013
10:29 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
17:14 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
17:14 -!- justin_kruger [[email protected]] has quit [EOF From client]
22:25 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Sun Aug 18 2013
08:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:44 -!- Callum [[email protected]] has joined #mctxuwa_softdev
11:45 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
12:00 -!- jtanx [[email protected]] has quit [Ping timeout]
12:03 -!- jtanx_ [[email protected]] has quit [Ping timeout]
12:04 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:53 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
22:37 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
--- Day changed Mon Aug 19 2013
08:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:43 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
12:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:34 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
17:42 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
20:07 < jtanx> just so you know, I'm changing the JSON functions
21:04 < sam_moore> Ok, I already pushed some stuff to github
21:05 < sam_moore> But we can get it to merge
21:05 < sam_moore> I ended up just using printf to make part of the JSON in the SensorHandler anyway
21:06 < jtanx> depending on where SensorHandler is
21:06 < jtanx> that may or may not work
21:06 < jtanx> inside of fastcgi.c it willwork
21:06 < jtanx> outside it won't
21:07 < jtanx> oh ok
21:07 < jtanx> I see
21:07 < jtanx> so that's fine
21:08 < jtanx> it might be best not to use a do while loop 
21:08 < jtanx> because if no arguments are passed
21:08 < sam_moore> Ah, right
21:08 < jtanx> then the keypair function will return null
21:09 < jtanx> while ((params = FCGI_KeyPair(params, &key, &value)))
21:09 < jtanx> will work fine
21:10 < sam_moore> The KeyPair function looks like it can return an empty string though, in which case I was getting the sensor_id parsed twice when I was testing it
21:10 < jtanx> what was your input string?
21:11 < sam_moore> "http://localhost/api/sensors?id=0"
21:11 < jtanx> looks fine from this end
21:11 < jtanx> http://mctx.us.to:8080/api/sensors?id=0
21:11 < jtanx> it might be because of your do while loop
21:12 < jtanx> yeah it will be because of that
21:12 < sam_moore> The do while loop causes problems when there is an empty string
21:13 < sam_moore> ie: No parameters are passed
21:13 < jtanx> ok let's just put it this way; FCGI_KeyPair was designed to use a while loop
21:13 < sam_moore> Ok, sure
21:13 < sam_moore> I had some problems with just a while loop, but I'll try again
21:13 < jtanx> yeah about that JSON stuff
21:13 < jtanx> I'm still trying to think of a good way to do that
21:13 < jtanx> especially with the array stuff
21:19 < sam_moore> I'm not sure what I did before, but a while loop seems ok now
21:19 < jtanx> heh
21:21 < sam_moore> Ok, I have to go now
21:21 < sam_moore> I might not be able to do much tomorrow, we'll see
21:22 < jtanx> ok yep
21:35 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
21:55 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:15 -!- Callum [[email protected]] has joined #mctxuwa_softdev
22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
23:08 -!- Callum [[email protected]] has quit [EOF From client]
23:11 -!- Callum [[email protected]] has joined #mctxuwa_softdev
23:14 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
23:17 -!- Callum [[email protected]] has joined #mctxuwa_softdev
23:35 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Aug 20 2013
07:44 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:11 -!- jtanx [[email protected]] has quit [Ping timeout]
09:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:11 -!- jtanx [[email protected]] has quit [Ping timeout]
10:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:11 -!- jtanx [[email protected]] has quit [Ping timeout]
14:28 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:06 -!- Callum [[email protected]] has joined #mctxuwa_softdev
15:06 < Callum> hey same
15:06 < Callum> sam*
15:20 < jtanx> :>
15:22 < Callum> he literally set himself to away as soon as i said that
15:45 < jtanx> urgh this json stuff is doing my head in
15:57 < sam_moore> Callum: I've been set to away since last night
15:57 < Callum> o.O not according to my client
15:58 < sam_moore> Anyway, we are definitely using the Beaglebone, Electronics has ordered one, they seemed to think they'd have to program it but I corrected them
15:58 < Callum> ...why would they have to program it? wtf did they think we were doing?
15:59 < sam_moore> They probably thought all we had to do was the GUI and not any of the other software? I don't know. But the guy seemed relieved anyway.
15:59 < Callum> and was gonna ask if you remembered anything about the pi meson decay question for physics (how do you get the anti-neutrinos momentum, or do you assume it to be 0 as well? but then it doesnt really make sense with conservation of momentum)
16:00 < sam_moore> Woah, I don't remember the assignments in that much detail
16:00 < Callum> was hoping you would :p
16:00 < sam_moore> No, I just have vague memories of algebra
16:01 < sam_moore> And looking through notes
16:01 < Callum> hmm. i cant seem to find anything in the notes
16:01 < Callum> because he says to assume the rest mass of the anti-neutrino is 0
16:02 < Callum> and i don't really remember much in regards to energies and 0 rest mass ;/
16:02 < jtanx> I talked to someone who did computer vision before
16:02 < jtanx> and he's really doubtful that you can get accurate readings off a webcam
16:02 < sam_moore> Callum: I don't think you can assume the momentum is zero, other than that, I don't have much to offer
16:02 < Callum> the question also says to have it in terms of m(pi) m(e) and c
16:03 < Callum> and yea thats what i thought. it doesnt make sense to do that. just cant remember how to do it D;
16:03 < Callum> @jeremy yea well, its a pain but possible
16:04 < Callum> really comes down to how good your camera is/sampling rate/how quickly you can process it. 
16:04 < sam_moore> How about you do some experimenting with a webcam and see what you can do with it?
16:04 < Callum> but you can get some pretty good webcams nowadays (but then again the better it is the longer it takes to process)
16:04 < jtanx> personally, I don't think it will work
16:04 < sam_moore> It looks like we might just end up streaming images diretly to a website
16:04 < Callum> i don't have any
16:04 < Callum> yea well even if thats all we do we still need the camera
16:05 < Callum> spose i could use my laptop one but i doubt that would be very good
16:05 < Callum> could run it through the canny algorithm and see what it produces
16:06 < sam_moore> Sounds like an idea
16:07 < sam_moore> A good idea specifically
16:07 < jtanx> about the sensorhandler
16:07 < sam_moore> Yes?
16:07 < jtanx> do you envision leaving it in fastcgi.c permanently
16:07 < jtanx> or for that matter any other handlers
16:07 < sam_moore> I was kind of thinking there would be a "handlers.h" and "handlers.c"
16:08 < sam_moore> Just to make things more organised
16:08 < jtanx> yeah
16:08 < jtanx> I'm trying to export enough of the functionality
16:08 < jtanx> to do that
16:08 < jtanx> but the json thing is annoying
16:08 < jtanx> especially when you need to spit out arrays
16:09 < jtanx> unless you have something like FCGI_Printf
16:09 < jtanx> and it's up to you to format it correctly
16:09 < Callum> bloody physics lecture video is laggy. gonna have to download it and hope for the best. fuck echo
16:10 < jtanx> compared to lectopia you get 2x filesize with no visible benefit in quality
16:10 < Callum> they're both shit.
16:10 < sam_moore> You could have seperate "BuildJSON_Key" and "BuildJSON_Value" functions, with a "BuildJSON_ValueArray" maybe
16:10 < Callum> haha
16:11 < sam_moore> FCGI_Printf is Ok though, it's not too much formating
16:11 < jtanx> the problem with the buildjson_* stuff
16:11 < jtanx> is it gets very verbose
16:12 < jtanx> and you can probably come up witha  situation that breaks it too
16:12 < jtanx> and don't get me started on value types
16:12 < sam_moore> Haha
16:14 < sam_moore> We can always just send plain text and make James turn it into JSON :P
16:14 < jtanx> ahaha
16:14 < jtanx> yeah that could work
16:15 < jtanx> mm 
16:15 < jtanx> this is where java is good
16:15 < jtanx> or any other higher level language
16:21 < jtanx> ok so it's a bit of both, but how about: FCGI_JSONKey(key) and FCGI_JSONValue(format, ...)
16:22 < sam_moore> That looks good
16:25 < jtanx> I'm also adding long/double types for the BuildJSON function, just for convenience
16:25 < jtanx> any preference to naming conventions?
16:26 < jtanx>  FCGI_BuildJSONLong
16:27 < sam_moore> Seems OK
16:28 < sam_moore> I need to go do some ENSC1001 stuff (hooray)
16:29 < jtanx> yuck
16:30 < Callum> hhaha
16:30 < Callum> have fun :p
16:30 < Callum> although i cant really talk. about a days worth of physics and a days worth of ensc3016 shit i should get through, on top of mctx and geng4402 stuff. yay for being behind already
16:38 < Callum> well iv got an answer for the first part (second part should be the same process). just hope its right :s
16:46 < jtanx> ok, time to merge this into the server code
19:47 < jtanx> hmm interesting - it crashes if compiled with clang but not with gcc
19:49 < jtanx> probably just a bug in clang 3.2
20:08 < jtanx> ok, just submitted a pull request to update the fastcgi stuff
20:08 < jtanx> for now I moved Sensor_Handler to sensor.c
20:09 < jtanx> the status codes have all changed
20:09 < jtanx> If you absolutely cannot process anything given the input arguments, you call FCGI_RejectJSON
20:10 < jtanx> If you fail for some other reason (e.g unauthorized access), you use FCGI_BeginJSON with the appropriate status code
20:10 < jtanx> With RejectJSON, it sends a HTTP 400 code so any query through AJAX/jQuery will fail with no extra info
20:11 < jtanx> With BeginJSON, the HTTP code is always 200 OK, so you are able to transmit extra info if it failed for another reason
20:12 < jtanx> BeginJSON will automatically add the module handler name + the status code
21:47 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
--- Day changed Wed Aug 21 2013
00:53 -!- Callum [[email protected]] has quit [EOF From client]
07:45 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:57 < jtanx> hmm
11:57 < jtanx> I just had a play with the sensor stuff
11:57 < jtanx> and I trialled a 'double buffer' scheme
11:57 < jtanx> instead of the binary file idea
11:57 < jtanx> seems to work okay, and it guarantees that a point won't be returned to the user if they have already received it
12:35 < jtanx> urgh
12:35 < jtanx> just worked through some stupid bug
12:37 < jtanx> I think it's because make didn't recompile something because it thought it hadn't changed
12:38 < jtanx> probably the header files
12:50 < jtanx> you can see the double buffer method in this branch: https://github.com/jtanx/MCTX3420/tree/doublebuffer
12:58 < jtanx> one issue though is that writing out csv instead of binary file takes up a lot more space
14:49 -!- james__ [[email protected]] has joined #mctxuwa_softdev
14:49 < james__> Hey
14:50 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
18:32 -!- Callum [[email protected]] has joined #mctxuwa_softdev
19:48 -!- jtanx [[email protected]] has quit [Ping timeout]
19:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
23:12 -!- jtanx [[email protected]] has quit ["･_･"]
--- Day changed Thu Aug 22 2013
00:46 -!- Callum [[email protected]] has quit [EOF From client]
08:19 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:00 -!- jtanx [[email protected]] has left #mctxuwa_softdev []
13:19 -!- callum [[email protected]] has joined #mctxuwa_softdev
13:20 < callum> hey
13:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:35 -!- callum [[email protected]] has quit [Ping timeout]
15:07 -!- callum [[email protected]] has joined #mctxuwa_softdev
15:07 < callum> sam you still at uni?
15:22 < callum> or jeremy if you remember what he used to compile the file. i'v managed to get it to recognise the header files but now its complaining about not being able to find the libraries.
15:34 < jtanx> um
15:34 < jtanx> I can't remember
15:34 < jtanx> didn't you use pkg config to find out
15:36 < jtanx> try this http://opencv.willowgarage.com/wiki/CompileOpenCVUsingLinux
15:54 -!- callum [[email protected]] has quit [EOF From client]
21:43 -!- jtanx [[email protected]] has quit ["._."]
22:08 < sam_moore> gcc -o opencv opencv.c -I/usr/include/opencv -lopencv_core -lopencv_highgui -lopencv_imgproc
22:08 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
22:08 < sam_moore> Oh... there's no one here
22:08 < sam_moore> Well, if you read the IRC logs when they're commited to git, you'll see it. Good luck.
--- Day changed Fri Aug 23 2013
07:42 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
07:49 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
07:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
10:02 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:12 -!- jtanx [[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
10:13 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
12:30 < jtanx_> um
12:30 < jtanx_> do you know how you connected the relay board to the sensor board
12:30 < jtanx_> for the soldering lab
12:45 < jtanx_> and what sort of wire did you use?
12:58 < jtanx_>  brb
12:58 -!- jtanx_ [[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
13:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
--- Log opened Sat Aug 24 17:07:53 2013
17:07 -!- matches [[email protected]] has joined #mctxuwa_softdev
17:07 -!- ServerMode/#mctxuwa_softdev [+nt] by irc.eversible.com
17:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
17:07 -!- Irssi: Join to #mctxuwa_softdev was synced in 1 secs
17:08 -!- You're now known as sam_moore
--- Day changed Mon Aug 26 2013
11:11 -!- matches [[email protected]] has joined #mctxuwa_softdev
11:11 -!- matches [[email protected]] has left #mctxuwa_softdev []
11:12 <@sam_moore> Thought I might have the wrong server
17:18 <@sam_moore> I do have the wrong server!
17:19 -!- sam_moore [[email protected]] has left #mctxuwa_softdev [I have the wrong server!]
--- Log closed Mon Aug 26 17:19:05 2013
--- Log opened Mon Aug 26 17:19:34 2013
17:19 -!- sam_moore [[email protected]] has joined #mctxuwa_softdev
17:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
17:19 -!- Irssi: Join to #mctxuwa_softdev was synced in 5 secs
17:19 < sam_moore> !motd
17:20 < sam_moore> '!motd'
17:20 < sam_moore> MctxBot: You're broken
17:20 < sam_moore> Oh wait, never mind
18:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:08 < jtanx> :P
18:09 < jtanx> you can change the message if you want
21:03 -!- jtanx [[email protected]] has quit ["brb"]
21:12 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Aug 27 2013
07:40 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
07:54 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
17:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:11 < jtanx> lol
19:11 < jtanx> the camera that we were using for the soldering lab inserted a bunch of wavy lines/static into the video
19:12 < sam_moore> It's an effect
19:14 < jtanx> nah
19:14 < jtanx> the camera was actually broken
19:15 < sam_moore> (I figured that)
19:15 < sam_moore> You could pretend it's supposed to be an 80s style video?
19:15 < jtanx> yeah that could work
19:16 < jtanx> have you done it yet?
19:18 < sam_moore> No :S
19:20 < jtanx> well
19:21 < jtanx> according to the manual, you need to connect a wire from R5 on the sensor board to the relay board
19:21 < jtanx> problem was we already chopped off the lead on R5
19:22 < jtanx> another group connected the wire to the LEd though
19:22 < jtanx> seemed to work
20:02 < jtanx> so are we using clock_gettime?
20:08 < sam_moore> I think so, we can use CLOCK_MONOTONIC_RAW if we are paranoid about the system time getting changed
20:08 < sam_moore> Or we can just use CLOCK_REALTIME if we aren't
20:09 < jtanx> I thought CLOCK_MONOTONIC was supposed to be best, because the RAW version wasn't compensated for temp/other stuff
20:10 < jtanx> http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic
20:10 < jtanx> about the FCGI loop blocking
20:10 < jtanx> you can switch to FCGX_ methods
20:10 < jtanx> I think
20:11 < jtanx> but is it really necessary
20:20 < jtanx> about the valgrind comment in sensors.c
20:20 < jtanx> this is probably it: http://stackoverflow.com/questions/5844242/valgrind-yells-about-an-uninitialised-bytes
20:23 < sam_moore> It's probably not necessary to stop the FCGI loop blocking, don't worry about it
20:25 < sam_moore> Yeah, I didn't initialise the buffers anywhere
20:25 < jtanx> actually I can't reproduce that message
20:25 < sam_moore> Hmm
20:26 < jtanx> about the sensor times
20:27 < jtanx> what about if you all reference it relative to some point
20:27 < jtanx> eg
20:27 < sam_moore> The epoch :P
20:27 < jtanx> lol
20:27 < jtanx> I mean
20:28 < jtanx> when you get sensor data, you store the difference in time between the start of recording and now
20:28 < sam_moore> Sure, that makes more sense
20:29 < sam_moore> Just give the client the start of recording time and they can convert it to a time of day / day in the calendar themselves
20:30 < jtanx> yeah
20:30 < jtanx> you could have a specific request to return the starting time
20:30 < jtanx> then it's implicit for all requests
20:30 < jtanx> btw I submitted a pull request for the nginx configs
20:32 < sam_moore> Ok
20:32 < sam_moore> I've added you to collaborators so you can merge them yourself if you need to
20:33 < jtanx> ok
20:35 < jtanx> huh
20:35 < jtanx> http://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
20:41 < sam_moore> Nice
20:42 < sam_moore> "Currently you can not access Ethernet" Not so nice
20:42 < sam_moore> Although this is dated 2011
21:18 -!- jtanx [[email protected]] has quit ["bye"]
--- Day changed Wed Aug 28 2013
08:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:08 -!- MctxBot [[email protected]] has quit [Connection reset by peer]
10:11 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
10:39 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
15:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:48 -!- Callum [[email protected]] has joined #mctxuwa_softdev
16:31 < jtanx> huh
16:31 < jtanx> firefox's javascript debugger is pretty cool
16:31 < sam_moore> Firebug? Yeah
16:35 < jtanx> nah the inbuilt one
16:35 < jtanx> firebug's good for inspecting html though
16:35 < jtanx> haven't used firebugs js debugger yet
16:35 < sam_moore> Oh, I didn't know they had an inbuilt one
16:36 < jtanx> Ctrl+Shift+K
16:36 < sam_moore> Of course I normally use Iceweasel, which is currently built as firefox 10.0.2 with a different name
16:36 < jtanx> well that's about 10 releases behind
16:36 < sam_moore> That looks pretty similar to firebug anyway
16:55 < jtanx> inline conditionals in javascript are whack
16:55 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
16:55 < sam_moore> I haven't done much javascript, but a lot of it does seem whack
16:56 < sam_moore> jtanx: What are you working on in JavaScript?
16:56 < jtanx> unit tests
16:57 < sam_moore> Cool
17:01 -!- Callum [[email protected]] has quit [Ping timeout]
17:01 -!- Callum_ is now known as Callum
17:18 < jtanx> javascript in general is annoying me though
17:25 < Callum> when exactly is this soldering lab due? fucking thing.
17:27 < jtanx> next friday
17:27 < Callum> it says week 5 on lms
17:27 < jtanx> sept 6
17:27 < Callum> where's it say this?
17:27 < jtanx> yeah he made an announcement
17:27 < jtanx> that it's wrong
17:27 < jtanx> somewhere
17:28 < Callum> sigh. this unit..i swear
17:28 < Callum> if it really is next week then i'd be so relieved
17:28 < Callum> wow
17:28 < Callum> he made an announcement today..
17:28 < Callum> wait yesterday
17:29 < jtanx> still got that central plant fbd to do
17:29 < Callum> why hasnt LMS emailed me a notification? (/end spam)
17:29 < Callum> yea i know
17:29 < Callum> which i think i have it pretty much done
17:29 < Callum> not 100% sure on it though
17:29 < Callum> and whether to add pumps and shit into it
17:29 < jtanx> what did you have on it?
17:30 < Callum> HA as i say that i check my phone and i have the message about the announcement
17:30 < jtanx> and what did you call the chiller things?
17:30 < Callum> pretty much just the 4 chillers, a line showing it can go back (they're literally called chillers ahha(
17:31 < Callum> then i had another part to show the chillers (evaporation/condensor/compressor and cooling tower is connected to condenser) 
17:31 < jtanx> ook
17:31 < Callum> however
17:32 < Callum> im not sure about the input/output of the chiller
17:32 < Callum> because stuff online shows it to be the evaporator 
17:32 < Callum> but isnt it water being pumped?
17:32 < jtanx> I think there were pumps on the output
17:33 < jtanx> were there three outputs?
17:33 < Callum> also not sure if i should/wherte to add the tank (yea ofc theres pumps but not sure to put them in to the diagram, pretty much everything is pumped)
17:33 < Callum> outputs where?
17:33 < jtanx> North/Sout/East distribution things
17:33 < jtanx> iirc
17:33 < jtanx> yeah not sure whether to add tank or not
17:34 < Callum> oh that, i didnt bother with that
17:34 < Callum> just how did the chiller connect with the rest of the plant?
17:34 < Callum> was the evaporator the input/output?
17:34 < Callum> because the chiller feeds out to the water tower and the tower feeds back into the chiller (i think)
17:36 < Callum> also what was the thing called? that allowed water to flow back and forth bypassing the chillers. back something?
17:36 < Callum> really they should have told us before we went in we had to do this. some lazy fucks like me dont read the outline so i didnt take notes..or try to commit stuff to memory :po
17:39 < jtanx> the bypass?
17:39 < jtanx> I haven't gone into detail
17:39 < jtanx> so I just have chiller
17:39 < jtanx> and cooling tower
17:39 < jtanx> maybe I should
17:40 < Callum> remember how tehre was 4 chillers, and they would only run what was needed.
17:40 < jtanx> yeah
17:40 < jtanx> how many cooling towers?
17:40 < Callum> and if they had more than they needed there was a pipe to flow back, or if they had some chilled water from the tanks or w.e it bypassed chillers
17:40 < Callum> i dont know, but im not sure how to show it all
17:40 < Callum> im sure what iv got is somewhat decent
17:41 < jtanx> I used visio and I ended up spending so much time trying to get the lines rihgt
17:41 < jtanx> probably would have been faster to hand draw it
17:41 < jtanx> still not finished too
17:41 < Callum> haha im fiarly sure i read somewhere it was hand drawn :p
17:41 < jtanx> meh I suck at drawing
17:42 < Callum> maybe not. "This is to be drawn and annotated on single A4 page"
17:42 < Callum> i dont think they'll be picky
17:42 < jtanx> and there's lines everywhere
17:42 < Callum> really? how do you have lines everywhere?
17:42 < jtanx> ok so chiller
17:42 < Callum> it's a fairly simple system. unless i'v done it wrong :s
17:43 < jtanx> has warm chilled water (1), chilled coolant (2), hot coolant (3), chilled chilled water(4), control line (5), (maybe) sensor back to controller (6)
17:43 < jtanx> that's ~5 lines in/out of one box?
17:44 < Callum> hmm. havent included coolant or control/sensor
17:44 < Callum> maybe i should :S
17:44 < jtanx> and an operator
17:44 < jtanx> to the controller
17:45 < Callum> thing is it asked for a high level FBD though
17:45 < Callum> which means not very detailed
17:45 < Callum> or maybe it didnt?
17:45 < jtanx> yeah, so do you need to show condensor/evaporator
17:45 < jtanx> I just have a chiller box
17:46 < jtanx> anyway... afk ~10 mins
17:46 < Callum> the condensor/evaporater is part of the chiller isnt it?
17:46 < Callum> ok
18:10 < Callum> anyone finished reading chapter 4 of the notes?
18:11 < jtanx> what's that
18:11 < Callum> sensors
18:12 < Callum> so dull :l
18:12 < Callum> and pretty much no chance to remember enough of it. quiz tomorrow is going to be fun.. 
18:12 < jtanx> oh 
18:13 < jtanx> shit
18:13 < jtanx> have to study for that
18:13 < Callum> rofl
18:14 < jtanx> :/
18:15 < Callum> gonna just have to wing most of them again like last time most likely. 
18:15 < jtanx> probably
18:15 < jtanx> Well, the unit testing thing works http://mctx.us.to:8080/unit-tests/
18:15 < jtanx> now what unit tests should there be
18:18 < Callum> not sure.
18:25 < Callum> brilliant! the notes show a false colour image built from a black and white image...while printed in black and white.
18:34 < jtanx> :P
19:50 < jtanx> um
19:50 < jtanx> did we get around to doing the sparkplus thing
19:54 < jtanx> we need to do it before the end of the week
19:54 < Callum> umm.
19:54 < Callum> actually justin already set up the group
19:54 < Callum> so you need to hurry up and join before we have to recreate the group :P
19:54 < jtanx> nah it expired
19:54 < Callum> wait already?
19:54 < Callum> zzz
19:55 < jtanx> 5 hr deadline
19:55 < Callum> and adrian said it was 24Hr, whats with this 5 hour shit
19:55 < jtanx> so... we need to try again
19:55 < jtanx> when everyone's available
20:11 -!- Callum [[email protected]] has quit [Ping timeout]
20:49 -!- jtanx [[email protected]] has quit ["ha"]
--- Day changed Thu Aug 29 2013
07:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:16 < jtanx> firefox blocks ajax calls if you try to run the file locally :/
09:45 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
13:33 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:24 -!- james__ [[email protected]] has joined #mctxuwa_softdev
14:25 < james__> Hey Jeremy. Is there a way to find my login hash key if i am already logged into the api?
14:28 < jtanx> um
14:28 < jtanx> right now you should store it
14:29 < jtanx> just declare a global variable and set it to the hash
14:30 < jtanx> or if you have made a class
14:30 < jtanx> just make it an element
14:31 < james__> I'm still logged in from ages ago and i can't logout so i can get a different key that works
14:31 < jtanx> that
14:31 < jtanx> ok
14:31 < james__> Possibly a bug that needs fixing? 
14:31 < jtanx> so the way it works right now is there's a 3 minute timeout on the key
14:31 < jtanx> no
14:31 < jtanx> there's actually two layers
14:32 < jtanx> the password that you enter first (mctxadmin) is what's called HTTP basic authentication
14:32 < jtanx> this lets you gain access to /api/login
14:32 < james__> Well i tried loging in again and its saying i am already logged in
14:32 < jtanx> when you reach /api/login you get the access key
14:32 < jtanx> there's a three minute timeout on the key
14:32 < jtanx> if you wish to invalidate the key
14:33 < jtanx> you call 
14:33 < jtanx>  /api/login?end
14:34 < jtanx> you can force getting a key by also calling /api/login?force
14:34 < james__> right. well it worked this time
14:34 < james__> Thats weird
14:34 < jtanx> so the only thing that the key prevents is stopping accidental concurrent use
14:34 < james__> Fair enough
14:35 < jtanx> Calling /api/login?force will force a new key to be generated and the old one to be invalidated
14:35 < james__> Okay
14:35 < jtanx> btw as I was working on unit testing
14:35 < jtanx> I did a function to retrieve the json data
14:36 < jtanx> http://mctx.us.to:8080/unit-tests/unit-tests.js
14:37 < james__> I will have a look.  I have some buttons working and stuff. Working on putting them in a seperate script file for easier editing etc
14:37 < james__> They don't seem to be playing nice at the moment
14:37 < jtanx> ok
14:38 < jtanx> how come it takes so much effort to get some buttons working
14:39 < james__> Getting the css to mesh with the js
14:40 < james__> I have buttons fine 
14:40 < james__> And they work
14:40 < jtanx> maybe you should get the functionality to work first
14:40 < jtanx> with the ajax queries
14:40 < jtanx> before worrying about styling them
14:40 < james__> I have the functionality pretty much working
14:41 < jtanx> so the querying works?
14:41 < james__> But i want the styling to work before we scale it up
14:41 < james__> That way its less hassle to fix it later
14:41 < jtanx> could you post it to git?
14:41 < jtanx> it'd be cool to have a look
14:45 < james__> The way i am thinking about having it set out is having a central index.html which just imports all the js. The js will contain all the functionlity seperated in to similar functions. Ie. all the buttons in one script
14:46 < jtanx> right
14:46 < james__> That should allow for ease of scaling and editing
14:46 < james__> Also changing id's and stuff
15:46 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
19:25 -!- Callum [[email protected]] has joined #mctxuwa_softdev
21:09 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
23:18 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Fri Aug 30 2013
09:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:16 -!- jtanx [[email protected]] has quit [EOF From client]
14:15 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
17:06 < jtanx> say you want to perform a command
17:06 < jtanx> eg move an actuator
17:07 < jtanx> and suppose checks have to be made against other sensors to ensure that this command is good to go
17:07 < jtanx> how are those checks going to be made?
18:10 < sam_moore> The Actuator Handler will call some sanity check against the most recent sensor data
18:11 < sam_moore> If they aren't, it will respond with some appropriate JSON or HTTP status code
18:11 < sam_moore> eg: "Try again later when the pressure is in the right range", or "Don't do that you silly person"
18:15 < jtanx> ._.
18:21 < jtanx> I wonder if there's a way to pull from your git repository without creating the 'merge branch master from...' commits
18:22 < sam_moore> I don't think so
18:22 < jtanx> I tried playing with rebasing but it doesn't work out so well
18:40 < jtanx> ok so I've committed some stuff to my repository that changes the handling of controls/actuators/login
18:41 < jtanx> I'm not sure if it's the best way to do it
18:41 < jtanx> though
18:41 < jtanx> What I did was get rid of /api/login
18:41 < jtanx> and instead have /api/control
18:41 < jtanx> All of the control code (eg actuators but may be other controls? Start/stop the whole thing?) has been moved to controls.c
18:42 < jtanx> You still need to supply username and password to access /api/control
18:42 < jtanx> and what was previously called  the 'authorization key'  is now the control key (ie who has control)
19:00 < sam_moore> Ok, I'll take a look at it later
19:01 < sam_moore> Don't worry about the merge messages, it's not a big deal
19:06 < jtanx> ok thanks
20:27 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
22:21 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
23:03 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Sat Aug 31 2013
09:09 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:30 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
17:40 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
20:48 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Sun Sep 01 2013
09:11 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:07 -!- Callum [[email protected]] has joined #mctxuwa_softdev
14:17 < jtanx> it'd have been cool to have written then server in python
14:19 < Callum> gah havent done much for this project this week. not sure what i should do either 
14:19 < jtanx> hmm
14:19 < Callum> so far behind in one of my units too. haha joys of uni
14:19 < jtanx> lol
14:20 < jtanx> werent we meant to get the camera stuff working or something
14:21 < Callum> well yea but thats more rosher getting stuff working on his end. still not really sure what's going on. need to find an efficient way to transfer data (which would be directly streaming but it seemed adrian wanted some sort of processing)
14:21 < Callum> guess i could start working on edge detection
14:21 < jtanx> james hasn't got much done afaik
14:21 < Callum> nah dont think he ahs
14:22 < jtanx> but man I was looking at the javascript stuff
14:22 < jtanx> and it's really annoying
14:22 < jtanx> everything in javascript is asynchronous
14:22 < jtanx> so you have a callback for an AJAX query, and it gets executed some time in the future
14:23 < jtanx> it's really hard to pass variables to the callback and then also retrieve them 
14:23 < Callum> hmm
14:23 < jtanx> i'm probably not doing it in the right fashion or something
14:28 < Callum> not sure. don't really understand this stuff myself. havent done much/any
14:45 < jtanx> flask is so cool
15:01 < jtanx> oh
15:02 < jtanx> maybe we can use cookies to store authorization
15:02 < jtanx> instead of in javascript
15:02 < jtanx> hmm
15:02 < jtanx> http://stackoverflow.com/questions/15722795/how-to-create-a-cookie-with-fastcgi-nginx-in-c
15:57 < sam_moore> Maybe a cookie is better, but couldn't you have a global variable that the JavaScript code sets in the callback?
15:57 -!- Irssi: #mctxuwa_softdev: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal]
15:59 < sam_moore> Ok, I'll do the simulated "digital" sensor and actuator
15:59 < sam_moore> We should make some kind of minimal gui in JavaScript
16:00 < sam_moore> I'm not sure what James has done, but there's nothing under git
16:02 < sam_moore> http://www.flotcharts.org/flot/examples/ajax/index.html is a good starting point for updating sensor graphs
16:03 < sam_moore> jtanx: I wouldn't worry about the login/authentication too much for this week
16:04 < jtanx> james said he got the buttons working but that's about it
16:04 < jtanx> he's more concerned about issues with styling them than getting a fully fledged gui
16:04 < sam_moore> I think actually having a gui is more important than having a pretty gui
16:04 < sam_moore> At the moment anyway
16:05 < jtanx> yeah
16:05 < jtanx> it would be great to have *something*
16:05 < jtanx> the problem with js
16:05 < jtanx> is from what i've seen, the callback occurs in the jQuery file
16:06 < jtanx> so you can't set global variables in say sensors.js
16:06 < jtanx> and expect to be able to read/set them in the callback
16:06 < sam_moore> Hmm, that's wierd
16:06 < jtanx> what really shits me about javascript is variable handling
16:06 < sam_moore> Hang on, let me have another look at the only project I ever used jQuery for... :P
16:07 < jtanx> you can pass one/none/more than specified parameters
16:07 < sam_moore> It was a chess game, so it should definietly be possible to modify variables in the callback function
16:07 < jtanx> yeah there's probably a way, I just don't know it
16:08 < jtanx> about the actuators
16:08 < jtanx> I've already got something working in my repository
16:08 < jtanx> but I don't really like how I've done it
16:30 < sam_moore> I'm making a minimal gui (it will be able to plot something, and have a button); we can either ditch it or improve on it later
16:31 < jtanx> sounds good
16:35 < sam_moore> Callum: If you want to make a (really awful but possibly looking good enough at this stage for Adrian) "streaming" images thing
16:35 < sam_moore> You can have your program continuously save to a file
16:35 < sam_moore> And a html page that just has "<meta http-equiv="refresh" content="0">" in the header
16:35 < sam_moore> With a link to the image
16:36 < Callum> alright il look into it
16:36 < sam_moore> It's absolutely aweful, but it will give the effect of a really laggy video
16:36 < jtanx> nice :P
16:36 < sam_moore> You can improve it (if you get time) by having 2 images instead of one, with a symbolic link to swap between them
16:38 < sam_moore> I'll bring the raspberry pi with the webcam tomorrow and we'll put everything on it to show Adrian
16:38 < jtanx> hehehe
16:38 < jtanx> can you install ffserver on the raspi?
16:39 < sam_moore> Probably
16:40 < jtanx> actually
16:41 < jtanx> does our code run on the raspi?
16:50 < sam_moore> Yes, at the moment
16:54 < Callum> how are we integrating my code into it?
17:01 < sam_moore> Keep it as a seperate process for now
17:01 < Callum> alright
17:01 < sam_moore> I'll modify the "run.sh" script to start both of them
17:01 < sam_moore> Sigh javascript
17:01 < sam_moore> So useful and yet so horrible
17:02 < sam_moore> Still, I think if we can get our heads around it it is actually a nice way to do this
17:09 < jtanx> the camera thing or the api or both?
17:24 < sam_moore> The API
17:24 < Callum> ok so how do i link to the image? (
17:24 < sam_moore> Just put a html file in the /server directory for now
17:25 < sam_moore> With <img src="path_to_image"> in the body somewhere
17:29 < Callum> where are we going to put the images?
17:31 < sam_moore> /server/images (?)
17:31 < sam_moore> Wherever it seems logical I guess
17:33 < sam_moore> If either of you are available earlier on Monday, I'm free for pretty much the whole day
17:33 < sam_moore> Do you want to meet earlier and actually do coding as a group?
17:37 < sam_moore> Dammit why does javascript remove the [] brackets when printing string representations of arrays
17:37 < sam_moore> How are you supposed to tell what dimensions the array has...
17:37 < jtanx> if you want sample code of how I printed the array of sensor values
17:37 < jtanx> see the unit tests
17:37 < sam_moore> Ok, thanks
17:37 < jtanx>    for (var i = 0; i < data.data.length; i++) {
17:37 < jtanx>      result += data.data[i][0]  + ":" + data.data[i][1] + ", ";
17:37 < jtanx>    }
17:56 < Callum> ok well iv done trhat, i think. you should probably check it to make sure its right
17:58 < Callum> sent pull request. and i'v got food so brb
17:58 < sam_moore> Ok, thanks
17:59 < sam_moore> jtanx: You're right, altering variables on a successful ajax call is a pain in the ass
17:59 < jtanx> hehe
17:59 < sam_moore> ... You can modify html attributes really easily though
17:59 < jtanx> true
17:59 < jtanx> that's what I was thinking
17:59 < sam_moore> Must resist urge to store data in a comment
17:59 < jtanx> have a hidden input field?
18:01 < jtanx> I must say that the firebug debugger and inbuilt web console were both quite useful
18:02 < sam_moore> Yes, I've got firebug running
18:04 < jtanx> I was looking at flask and it was ridiculously easy to set up a similar API in python
18:05 < sam_moore> Do you want to change to python then?
18:06 < sam_moore> Don't we still have to do the javascript though?
18:07 < sam_moore> The API we have at the moment isn't that terrible
18:07 < jtanx> nah
18:07 < jtanx> it's probably best to stick with what we have
18:07 < jtanx> the javascript stuff would remain the same yeah
18:09 < sam_moore> Ok
18:26 < sam_moore> Right... you can update global variables on a successful AJAX request
18:27 < sam_moore> If you put "var" in front of the variable in the global scope then the AJAX callback will just make a new local variable and modify that -_-
18:27 < sam_moore> But if you Don't put the "var" there, it will work
18:40 < jtanx> lol
18:41 < jtanx> but using global variables in javascript can get.... messy
18:41 < sam_moore> Mmm
18:42 < sam_moore> But doing pretty much *anything* in javascript is messy
18:42 < jtanx> yeah
18:42 < jtanx> true that
18:43 < sam_moore> I wonder...
18:43 < sam_moore> Should we just have one html page for each sensor/actuator
18:43 < sam_moore> And then the user can open multiple tabs?
18:45 < sam_moore> That's probably not very nice though
18:46 < sam_moore> I think we should return data about multiple sensors at a time
18:51 < jtanx> you'd probably want it all on one page
18:51 < sam_moore> Yeah
18:51 < jtanx> how many sensors are we talking about again
18:51 < sam_moore> 6 or 7 I think, + a camera
18:51 < jtanx> oh yeah
18:51 < sam_moore> Oh well, we can redesign it later
18:51 < jtanx> I guess we can design for max 7
18:52 < sam_moore> But it might be a good idea to query multiple sensors in one ajax request
18:53 < jtanx> yep
18:53 < jtanx> supply more than one id in a go?
18:53 < jtanx> could have an array (max size 7) that holds all the sensors you want to get data for
18:53 < jtanx> i guess
18:55 < sam_moore> It's probably more flexible to just add a "getall" key to the sensor module
18:57 < jtanx> oh yeah
18:57 < jtanx> I'm free until 12 tomorrow
18:57 < jtanx> do you want to work together before that?
18:58 < sam_moore> Sure
18:59 < sam_moore> Try G19 again, but if that doesn't work we can go to the physics lab, or the computer science labs
19:01 < jtanx> yeah ok
19:02 < jtanx> what time do you want to start?
19:04 < sam_moore> I'll probably get in around 9 or 10, depending on how much sleep I get
19:04 < sam_moore> Let's say 10:00
19:05 < sam_moore> Got to go, I'll be back later
19:05 < jtanx> ok
21:35 < sam_moore> I'm just going to use the same Sensor stuff for digital sensors
21:36 < sam_moore> Adding a second type of sensor seems needlessly complicated
21:36 < sam_moore> 1 = on and 0 = off
21:37 < sam_moore> Probably do the same for actuators (just have some sanity checks on the values you can set, both at the client and the server)
21:38 < jtanx> usually I'd just say 0 is off and not 0 is on
21:38 < sam_moore> Haha, fair enough
21:39 < jtanx> I kinda hate over-checking stuff :P
21:39 < sam_moore> The actual GetData function has to return something reasonably sane though
21:39 < sam_moore> It's easy to just make it only return 0 or 1
21:39 < jtanx> oh I was more talking about setting the value of the actuator 
21:39 < sam_moore> Right
21:40 < sam_moore> We should probably check for 0 or 1 anyway
21:40 < sam_moore> In case the user does something dumb
21:40 < jtanx> well
21:40 < sam_moore> Like think they are setting an analog sensor and put in like "200"
21:40 < jtanx> it should be the js code that's setting it
21:41 < jtanx> so if you write the code properly it shoul be ok
21:41 < sam_moore> "should be OK"...
21:41 < jtanx> you shouldn't access the api directly
21:41 < sam_moore> Alright, we'll see, but it's like, 1/2 a line of code to check :P
21:41 < sam_moore> Redundancy and all that
21:41 < jtanx> but even if they entered 200
21:41 < jtanx> well so what
21:41 < sam_moore> Yeah, but people *can* access the API directly
21:41 < jtanx> it'd just represet 1
21:42 < jtanx> represent
21:42 < jtanx> *
21:42 < sam_moore> How does the server know the difference between someone typing the URL and an AJAX request to the URL?
21:42 < jtanx> yeah
21:42 < sam_moore> Someone could go view source, "How can I break this... ah, what happens if I pass stupid values directly to the API"
21:42 < jtanx> well if you define that 0 is off and not zero is on
21:43 < jtanx> then it meets specs :P
21:43 < sam_moore> Ok, I suppose it doesn't really matter
21:44 < sam_moore> I respectfully disagree with the idea of having too many checks :P
21:44 < sam_moore> Unless we went "while (true) DoCheck();" or something like that
21:44 < sam_moore> That would be dumb
21:44 < jtanx> hahaha
21:45 < jtanx> but sometimes it gets really messy to maintain when you have that many checks
21:45 < jtanx> and then when you want to modify something it's a real pain
21:45 < jtanx> and really easy to break
21:45 < sam_moore> True, but a bounds check isn't that bad
21:46 < jtanx> yrue
21:46 < sam_moore> I mean, you have to convert the value that isn't zero to an "on" anyway, which requires a check
21:46 < jtanx> not really
21:46 < sam_moore> Depends on the actuator
21:46 < jtanx> you check if !value
21:47 < sam_moore> Alright
21:58 < jtanx> do you think there should be a stop/start method?
21:58 < jtanx> eg start the experiment
21:58 < jtanx> stop the experiment
22:28 < sam_moore> Yes, probably
22:28 < sam_moore> The stuff I wrote for Thread Exit conditions may actually help there...
22:29 < sam_moore> Remove the bit where the FCGI loop exits though
22:29 < jtanx> yeah 
22:41 -!- Callum [[email protected]] has quit [EOF From client]
23:09 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Mon Sep 02 2013
07:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:33 < sam_moore> Hi
08:33 < sam_moore> I managed to get a reasonable sensor plotting GUI done
08:35 < sam_moore> So, adrian wanted: 1) A digital sensor simulation (done) 2) Sensors plotted in GUI (done) 3) A test actuator in the GUI 4) Camera images in the GUI (sort of done, kind of)
08:35 < sam_moore> Was there anything else?
08:38 < sam_moore> I have to go to Uni, I'll be in G19 otherwise I'll send an email
08:38 < sam_moore> See you
08:42 < jtanx> ok then
09:02 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
09:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
13:06 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:12 -!- james__ [[email protected]] has joined #mctxuwa_softdev
13:15 < jtanx> hey
13:18 < james__> hey
13:18 < james__> I have the AJAX call working i am pretty sure
13:19 < jtanx> ok
13:19 < james__> Do you know if we have the beaglebones in yet?
13:19 < jtanx> I don't know
13:19 < jtanx> it should be ready soon though
13:19 < jtanx> anyway, sam got a gui with graphs semi working 
13:20 < jtanx> could you update your git repository with what you've done?
13:28 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
13:31 < jtanx> :(
13:31 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
18:12 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:46 -!- Callum [[email protected]] has joined #mctxuwa_softdev
19:17 -!- Callum [[email protected]] has quit [Ping timeout]
21:04 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Sep 03 2013
17:23 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:29 -!- jtanx [[email protected]] has quit [Ping timeout]
21:35 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
21:35 -!- jtanx_ is now known as jtanx
22:10 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Wed Sep 04 2013
07:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:35 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
08:35 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
08:49 -!- jtanx [[email protected]] has quit [Ping timeout]
08:51 -!- MctxBot [[email protected]] has quit [Ping timeout]
09:02 -!- jtanx_ is now known as jtanx
09:03 -!- MctxBot_ is now known as MctxBot
11:54 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
15:32 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:00 -!- jtanx [[email protected]] has quit [Ping timeout]
16:00 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
16:00 -!- jtanx_ is now known as jtanx
16:21 -!- jtanx [[email protected]] has quit [Ping timeout]
17:26 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
20:49 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Thu Sep 05 2013
08:19 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:34 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
13:22 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:51 < jtanx> hm, so to get clock_gettime to work, you need to use std=gnu99 instead of std=c99
18:52 < jtanx> do you think we should just stick with gettimeofday?
21:46 -!- jtanx [[email protected]] has quit [":3"]
--- Day changed Fri Sep 06 2013
09:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
12:05 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
13:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:05 < jtanx> I was just thinking, what sort of identification information is needed from the server?
16:05 < jtanx> The gui should have some understanding of what sort of sensors/actuators it needs to display
16:10 < jtanx> it might be enough to say this is API version x
16:10 < jtanx> and at version x, it's agreed that these id values correspond to these sensors/actuators etc?
16:19 < jtanx> anyway, what I've done for now is if asked, the api will list the sensor/actuator ids and the corresponding human readable string
16:19 < jtanx> api/?sensors&actuators
18:06 < jtanx> also, what do you think of keeping track of the number of points stored
18:07 < jtanx> then you can allow the user to request from where they want to retrieve data from and how many to retrieve
18:08 < jtanx> the only problem is that it wouldn't be time based, but based on the number of data points recorded
18:08 < jtanx> this method is simpler because you now the offset to use with fseek
18:08 < jtanx> if it's time based you have to search the data for the correct point
19:51 < sam_moore> All the above makes good sense
19:52 < sam_moore> If we can make a working "request X number of points" first instead of "request from time T onwards", we might be able to convert the latter to the former if necessary
20:04 < jtanx> ok I just submitted a pull request for some stuff
20:04 < jtanx> mostly the identification stuff and some reordering
20:04 < jtanx> FCGI_RejectJSON now requires that you give a description explaining why
20:05 < jtanx> when RejectJSOn is called, it's always logged along with the description, so some of the current log messages within the handler functions may be redundant
21:11 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Sat Sep 07 2013
10:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:29 < jtanx> hmm
18:29 < jtanx> what if you had two file pointers to the same file
18:29 < jtanx> one read only, one write only
18:29 < jtanx> then if you also kept track of how many points were written to the file
18:29 < jtanx> you don't need to have mutexes anymore
18:30 < jtanx> as long as you write the read/write calls carefully
18:44 < jtanx> ahp, may have spoken too soon
18:44 < jtanx> you'd still need a mutex around the read/write from/to the counter
18:45 < jtanx> I think...
19:07 < jtanx> but it might still be a good idea
21:38 < jtanx> I went the simple route
21:53 < jtanx> what I've got: /api/sensors?id=x&from=y&count=z
21:54 < jtanx> In dump mode:
21:54 < jtanx> If from < 0, then return from start, else from the given index (0-indexed)
21:54 < jtanx> if count < 0, then return all points, else return /at most/ that many points
21:55 < jtanx> in normal mode:
21:55 < jtanx> if from < 0, then return from the end (return the most recent points)
21:55 < jtanx> if count < 0, then return at most the default amount (SENSOR_QUERYBUFSIZ)
21:56 < jtanx> otherwise return /at most/ that many points
21:56 < jtanx> oh ya, if from >= 0 then return from that indicated index
21:57 < jtanx> it's only in my git repository for now because I haven't tested it enough and I'm still not sure how I should go about integrating it with the current code
21:58 < jtanx> (I basically rewrote Sensor_Handler and it has less error checks on the input; not sure if they're necessary or not)
21:59 < jtanx> Since requesting a huge range could impact on sensor readings due to the mutex, it may be better to at least restrict dumps to when the experiment is not 'running'
22:01 -!- jtanx [[email protected]] has quit ["~ that's it for now! ~"]
--- Day changed Sun Sep 08 2013
11:28 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:50 -!- Callum [[email protected]] has joined #mctxuwa_softdev
17:55 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
18:06 < Callum_> what was the server stuff you said to install? also what packages do i need?
18:07 -!- Callum_ [[email protected]] has quit [EOF From client]
18:07 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
18:09 -!- Callum [[email protected]] has quit [Ping timeout]
18:09 -!- Callum_ is now known as Callum
18:21 < jtanx> if you want to install the server, you need at least the 'nginx' and 'spawn-fcgi' packages
18:21 < jtanx> one nginx is installed you need to copy the config files from the git repository in
21:14 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
21:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:36 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
22:38 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Mon Sep 09 2013
09:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:59 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
10:13 -!- jtanx [[email protected]] has quit [Ping timeout]
10:54 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
11:30 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
13:27 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:48 -!- jtanx [[email protected]] has quit [Ping timeout]
14:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:25 -!- jtanx [[email protected]] has quit [Ping timeout]
15:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
20:33 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:01 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Sep 10 2013
17:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
17:25 < jtanx> it looks like we do need an sd card, at least to install the os onto it
17:26 < jtanx> http://beagleboard.org/Getting%20Started#update
17:41 < jtanx> http://avedo.net/653/flashing-ubuntu-13-04-or-debian-wheezy-to-the-beaglebone-black-emmc/
17:42 < sam_moore> Ok, we should write a BOM for next week then
17:42 < sam_moore> 1x SD Card
17:44 < jtanx> from what I understand
17:45 < jtanx> you write an image to the sd card
17:45 < jtanx> boot off the sd card
17:45 < jtanx> then you can write another image directly too the internal storage
17:45 < jtanx> after that you don't need the sd card any more
17:46 < sam_moore> Alright
17:46 < jtanx> http://www.armhf.com/index.php/boards/beaglebone-black/
17:47 < jtanx> any preference for ubuntu or debian?
17:48 < sam_moore> As a debian user, I'd have to say debian :P
17:49 < jtanx> hehe
17:49 < sam_moore> If it works on debian stable, we know it will work for at least the next 6 years
17:49 < jtanx> yup
17:49 < jtanx> debian should be fine
17:53 < jtanx> *correction; we need a microsd card
17:56 < jtanx> that's at least 2GB in size
17:57 < sam_moore> Ok
18:04 < jtanx> haha it's cheaper to buy a 4gb one than a 2gb one
18:35 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
19:11 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
20:15 < jtanx> Well I can confirm that angstrom doesn't have nginx precompiled - http://www.angstrom-distribution.org/repo/
20:57 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Wed Sep 11 2013
10:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:10 -!- jtanx [[email protected]] has quit [Ping timeout]
15:58 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:58 < jtanx> urgh
15:58 < jtanx> it took so long just getting internet access to the bbb
16:01 < jtanx> dhcp/dns issues
16:01 < jtanx> the debian image on the microsd is set to static ip 192.168.0.7
16:02 < jtanx>  /etc/resolv.conf should have the uwa nameservers in it, but it may have been rewritten by resolvconf
16:02 < jtanx> I've left it in g19
16:51 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
17:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:32 < jtanx> I've moved the 'current_time', 'start_time' and 'running_time' to the identify module instead of sticking it on every json response, because it's probably not information that will be required most of the time
19:37 < jtanx> actually, we may have to rethink those, especially if we introduce start/stop control
20:38 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Thu Sep 12 2013
08:49 -!- MctxBot [[email protected]] has quit [Connection reset by peer]
09:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:36 < sam_moore> I think I have some time after the tutorial today to work on stuff
09:36 < sam_moore> I take it we have the bbb now?
09:37 < sam_moore> I'll bring that crappy webcam
09:37 < sam_moore> Maybe look into sending images as part of the API, see if it's feasable to do it that way
09:38 < sam_moore> I think we can introduce start/stop control fairly easily
09:40 < sam_moore> "Mush Mush"
09:40 < sam_moore> Heh
09:41 < sam_moore> To reduce the load on the client, we might be able to send averaged data points instead of every data point
09:41 < sam_moore> You specify "averages per point"
09:42 < sam_moore> So each [time, value] pair is actually an average of X recordings
09:42 < sam_moore> In fact it's better to send [mean_time, mean_value, std_dev]
09:42 < sam_moore> The std_dev gives you an idea of noise and/or if the value is changing a lot
09:43 < sam_moore> And of course you can always specify a single average and it becomes equivelant to what we currently do
09:50 < jtanx> yeah
09:50 < jtanx> I'm free after the tute
09:50 < jtanx> I'm bringing in a router to make it easier
09:50 < jtanx> to work on the bbb together
09:51 < jtanx> yesterday it was so painful trying to get shit working 
09:51 < jtanx> dhcp issues, dns issues, internet connection sharing issues...
09:51 < jtanx> (mostly the fault of my own computer though)
09:51 < jtanx> btw I'm working on adding an extra function to FCGI to makeit easier to parse parameters
09:51 < jtanx> (hoepfully)
09:55 < jtanx> gtg see you at the tute
09:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
18:24 -!- Callum [[email protected]] has joined #mctxuwa_softdev
18:26 < Callum> would be easier to talk here...if everyone was on
18:35 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:41 < jtanx> did you bring the bbb home?
18:43 < sam_moore> Yep
18:44 < sam_moore> I'll put it back tomorrow morning
18:49 < jtanx> ok
19:15 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
19:28 -!- Callum [[email protected]] has quit [Ping timeout]
19:47 < jtanx> I'm so tempted to use bitflags for that request function
19:52 < jtanx> one thing that I need to do is to sanitise json string fields
20:18 < sam_moore> Sanitise? As in "make sane" or "make clean"?
20:18 < sam_moore> Um... if you think bitflags are necessary, I fully support you :P
20:19 < jtanx> as in
20:19 < jtanx> If I allow FCGI_JSONPair to also be passed a format string
20:19 < jtanx> then having stuff like \ or " or newline characters for eg in the string
20:20 < jtanx> is not a good idea
20:20 < sam_moore> Hmm
20:20 < jtanx> it's sorta like this:
20:20 < sam_moore> Well, writing the function to print out data (either as TSV or JSON)
20:20 < sam_moore> I've only been using FCGI_PrintRaw
20:20 < jtanx> yeah
20:20 < jtanx> but right now, you're logging messages in Server_handler
20:20 < jtanx> about invalid values
20:21 < sam_moore> Yes, I'm not sure how to deal with that
20:21 < jtanx> Sensor_handler*
20:21 < jtanx> so
20:21 < jtanx> eg Log(LOGERR, "Require \"all\" or an integer value: %s = %s", key, value);
20:21 < sam_moore> Yes
20:21 < jtanx> if I wanted to send that back to the client in FCGI_RejectJSON
20:21 < jtanx> there's the potential (...) that the user could hvae included a " in the value
20:22 < jtanx> so if you return it as part of your json response, then suddenly it's broken
20:22 < sam_moore> Oh, that sucks
20:23 < sam_moore> Perhaps treat Log messages seperately from JSON responses?
20:23 < jtanx> eg:  "description":" required an id, got 'blah-stray"'"
20:23 < jtanx> yeah
20:24 < jtanx> What I could do is just replace any special characters with space 
20:24 < jtanx> and return that in description
20:24 < jtanx> but keep the actual value in log
20:24 < sam_moore> Maybe
20:24 < sam_moore> You could also call FCGI_RejectJSON as soon as you get a special character
20:25 < sam_moore> Since we shouldn't have any key/values that use them
20:25 < sam_moore> (I think :P)
20:25 < jtanx> lol
20:25 < sam_moore> Whatever seems best
20:25 < jtanx> let me think about it some more
20:25 < sam_moore> Yeah, fair enough
20:25 < sam_moore> Um, another thing (sorry) is error messages that you might get independent of any request
20:26 < sam_moore> Like you suddenly have an I/O error on a file
20:26 < sam_moore> Currently we handle that with Fatal
20:26 < sam_moore> Which it would be convenient to keep; but instead of terminating the whole program, we need to notify the client somehow
20:26 < jtanx> that won't happen until the next request
20:27 < jtanx> what you could do is keep it exiting
20:27 < jtanx> when that happens, nginx sends 502 bad gateway
20:27 < jtanx> then if that's detected, send a link to the log file
20:27 < sam_moore> Yeah, that seems good
20:27 < jtanx> and a method to restart the software
20:28 < sam_moore> Do we want to notify the client of non-fatal errors or warnings though?
20:28 < sam_moore> Hmm
20:29 < jtanx> hmm
20:29 < jtanx> probably a good idea
20:29 < jtanx> but how
20:29 < sam_moore> The client could periodically request the log file and deal with messages?
20:30 < jtanx> It could just display it I guess
20:30 < jtanx> onus on the user to take action if required
20:30 < sam_moore> Sure, an alert might be nice though
20:30 < sam_moore> Perhaps have an extra log file that just has the most recent message in it (with a timestamp)
20:31 < jtanx> you could perform a regex on the text and highlight lines with warning or something
20:31 < sam_moore> The client just periodically looks at that and if it's a new message can alert
20:31 < sam_moore> Yeah that would work, as long as the file doesn't get too big
20:31 < sam_moore> It probably won't
20:31 < jtanx> well you could autoscroll it anyway
20:32 < jtanx> but ok maybe that's getting a bit ahead of ourselves
20:32 < sam_moore> Yeah, sure
20:32 < sam_moore> I'll get back to rewriting 90% of the sensor code :P
20:32 < jtanx> haha
20:32 < jtanx> currently, I've got
20:32 < jtanx> bool FCGI_ParseRequest(FCGIContext *context, char *params, FCGIValue values[], size_t count);
20:32 < jtanx> (any better suggestion for FCGIValue?)
20:32 < jtanx> (the name that is)
20:33 < jtanx> with 
20:33 < sam_moore> That's probably fine
20:33 < jtanx> typedef struct FCGIValue {
20:33 < jtanx>  const char *key;
20:33 < jtanx>  void *value;
20:33 < jtanx>  unsigned flags;
20:33 < jtanx> } FCGIValue;
20:33 < jtanx> you then do
20:33 < jtanx> something like:
20:33 < jtanx> FCGIValue values[2] = {{"sensors", &ident_sensors, FCGI_REQUIRED(FCGI_BOOL_T)},
20:33 < jtanx>                                   {"actuators", &ident_actuators, FCGI_BOOL_T}};
20:33 < sam_moore> Looks good
20:33 < jtanx> although I'm open to suggestions on those type names too
20:34 < jtanx> if you really have to
20:34 < jtanx> you can do something like FCGI_RECEIVED(values[0].flags)
20:34 < jtanx> to check if you received the argument or not
20:34 < sam_moore> If it's not too hard to implement, then OK
20:35 < jtanx> ?
20:35 < sam_moore> That looks reasonably nice
20:35 < jtanx> the #defines look less so:
20:35 < jtanx> #define FCGI_PARAM_REQUIRED (1 << 0)
20:35 < jtanx> #define FCGI_PARAM_RECEIVED (1 << 1)
20:35 < jtanx> #define FCGI_BOOL_T (1 << 2)
20:35 < jtanx> #define FCGI_LONG_T (1 << 3)
20:35 < jtanx> #define FCGI_DOUBLE_T (1 << 4)
20:35 < jtanx> #define FCGI_STRING_T (1 << 5)
20:35 < jtanx> #define FCGI_REQUIRED(x) ((x) | FCGI_PARAM_REQUIRED)
20:35 < jtanx> #define FCGI_IS_REQUIRED(x) ((x) & FCGI_PARAM_REQUIRED)
20:35 < jtanx> #define FCGI_RECEIVED(x) ((x) & FCGI_PARAM_RECEIVED)
20:35 < jtanx> #define FCGI_TYPE(x) ((x) & ~(FCGI_PARAM_REQUIRED | FCGI_PARAM_RECEIVED))
20:35 < sam_moore> In fact it's similar to how you use select(2)
20:35 < sam_moore> Wow, macros
20:35 < jtanx> :P
20:35 < jtanx> makes life easier
20:36 < sam_moore> Alright, this is C
20:36 < sam_moore> Yeah, FCGI_RECEIVED(values[i].flags) looks nice (from the point of view of actually using it anyway)
20:37 < jtanx> yeah it's ok
20:37 < jtanx> the only stickler is that hardcoded index
20:37 < jtanx> can't really do much about that though
20:37 < sam_moore> I can put an enum in the function
20:38 < jtanx> if you want; it might be more work to maintain the enum than anything though
20:39 < jtanx> but yeah, essentially if you require a parameter, you surround the type in FCGI_REQUIRED()
20:39 < jtanx> hopefully that part was clear
20:39 < sam_moore> Yep, I'm happy with that
20:39 < jtanx> cool
20:43 < jtanx> for the bool value, what behaviour do you think is better
20:43 < jtanx> always set the value to true, or invert the current value
20:44 < jtanx> right now it's set to always be true
21:06 < sam_moore> Um... always set to true?
21:09 < jtanx> yeah
21:29 < jtanx> oh
21:30 < jtanx> well I didn't need to escape after all
21:30 < jtanx> If you do something like this: http://mctx.us.to:8080/api?afa%22%22%22%22
21:30 < jtanx> it gets url encoded
21:30 < jtanx> http://mctx.us.to:8080/api?afa""""
21:30 < jtanx> I wonder if that's guaranteed
21:32 < jtanx> well, apparently it's not because IE doesn't escape it for you
21:32 < jtanx> so I did need to escape 
21:33 < sam_moore> There's no escape
21:46 < jtanx> wait wat
21:59 < sam_moore> (It's a pun)
22:00 < sam_moore> So I've made a DataFile structure to isolate it a bit more from the higher level Sensor related stuff
22:00 < sam_moore> Hopefully things make more sense
22:00 < sam_moore> I put in 2 seperate FILE* as well
22:00 < sam_moore> And got rid of the confusing "fill a buffer then dump the buffer to a file" loop
22:01 < sam_moore> Now it just writes each point to a file
22:01 < sam_moore> Hopefully it's thread safe enough
22:01 < sam_moore> Now... I just need to simplify the Sensor_Handler function...
22:02 < jtanx> > (It's a pun) 
22:02  * jtanx facepalm
22:03 < jtanx> hoho
22:03 < jtanx> ok 
22:03 < jtanx> I'll submit what I've done so far to git
22:08 < jtanx> callum
22:08 < jtanx> that code you submitted
22:08 < jtanx> I don't think it's right
22:08 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
22:09 < jtanx> the stuff with g_sensor_names, that's the human readable name of each sensor
22:10 < sam_moore> I've changed the name and how the sanity check gets called, but I've left the body unimplemented for now
22:12 < jtanx> it's with the pull request he submitted ~30mins ago
22:12 < sam_moore> Oh, ok
22:13 < sam_moore> Good thing I made a new branch for my changes
22:14 < jtanx> the pull request isn't merged yet
22:15 < sam_moore> Yeah, I don't think we should merge that, sorry Callum
22:17 < jtanx> ok just submitted the pull request
22:17 < sam_moore> I never put documentation on g_sensor_names I guess, sorry
22:17 < jtanx> I think I did though
22:17 < jtanx> but in the header file
22:18 < jtanx> which is annoying :/
22:18 < jtanx> (as in there's more than one spot to put documentation)
22:19 < sam_moore> Yeah... does one overwrite another?
22:19 < sam_moore> I'll just copy paste the same thing into the .c file
22:19 < jtanx> No idea how doxygen handles that
22:20 < sam_moore> I wonder how much fun I'll have merging these branches...
22:20 < jtanx> hehe
22:20 < jtanx> I'm not really sure if FCGI_ParseRequest will be that helpful or not
22:20 < jtanx> if you find it doesn't really help then we can scrap it
22:21 < sam_moore> Well it makes sense to seperate the code for getting key,value pairs from the code that does stuff with them
22:23 < jtanx> I guess
22:23 < sam_moore> I've basically moved a lot of functionality from sensor.c into a new file data.c under functions with the prefix "Data_"
22:24 < jtanx> ok
22:24 < sam_moore> data.c doesn't care anything about what the data is or where it came from, it just wraps around saving/reading/selecting ranges of DataPoints
22:25 < jtanx> sounds like a good idea
22:25 < jtanx> it might be of use in actuator code I guess
22:25 < sam_moore> Yeah, there's a DataFile structure that basically wraps around the binary file
22:25 < sam_moore> Yes, I was thinking that too
22:25 < sam_moore> Because we'll probably want to store DataPoints when an actuator gets changed
22:26 < jtanx> yeah true
22:27 < sam_moore> If the idea about using 2 FILE* is right... I don't think we really need any mutexes?
22:28 < sam_moore> There is an index that gets incremented, but since only one thread can write to it, the worst that can happen is you return one (maybe two at the extreme) less point than actually exists
22:29 < sam_moore> If you had 2 threads incrementing the index you'd need a mutex though
22:29 < jtanx> the problem is that setting a value is not guaranteed to be atomic
22:29 < jtanx>  i think
22:29 < sam_moore> Yes, sure
22:29 < jtanx> so while setting and you read it it could be indeterminate
22:29 < sam_moore> Mmm
22:30 < jtanx> I think you need mutexes around reading/writing the points_written(?)
22:30 < jtanx> index
22:30 < jtanx> but that's it
22:31 < jtanx> http://stackoverflow.com/questions/54188/are-c-reads-and-writes-of-an-int-atomic
22:31 < sam_moore> I'm not sure you do if you are writing in one thread and reading in another
22:31 < sam_moore> Ah, stackoverflow, OK
22:32 < jtanx> it's actually very architecture specific
22:32 < sam_moore> Yeah "Yes, no, hmmm, well it depends" is probably right
22:32 < jtanx> haha
22:32 < sam_moore> Well... there are no mutexes at the moment, but maybe I should get around to putting them in
22:32 < sam_moore> I think I had one thread writing and another reading in my parallel programming assignment and got full marks :S
22:33 < sam_moore> Threads are strange and magical
22:33 < jtanx> hey well it probably works 99% of the time
22:34 < sam_moore> Ah, it probably works if the size of the integer is smaller than the bus
22:34 < sam_moore> smaller or equal
22:34 < jtanx> too bad linux doesn't have something like InterlockedExchange
22:35 < sam_moore> I'll add mutexes in later then
22:35 < jtanx> One thing I liked about C++ was auto locks
22:36 < jtanx> (you could call some lock function and once that scope ended the lock ended too)
22:36 < sam_moore> That's nice
22:40 < jtanx> Ok, that's all I'm probably going to get done today
22:41 < sam_moore> Yeah, thanks
22:42 < jtanx> what's with the meeting tomorrow though
22:43 < sam_moore> I'm busy from 2:00pm until at least 4:00pm (maybe later)
22:43 < sam_moore> But I think I should be preparing for something before 2:00pm
22:44 < jtanx> ok, I'll probably come in around 1.30pm so I can work with Callum, and I'll stay on until whatever time
22:44 < sam_moore> Alright
22:45 < sam_moore> Check github in the morning, I'll push all my changes
22:45 < jtanx> ok I'll do that
22:45 < sam_moore> Hopefully they make sense, otherwise you can change everything back :P
22:45 < sam_moore> The wonders of git
22:45 < jtanx> haha I'm sure it'll make sense
22:46 < jtanx> after staring for a while
22:46 < sam_moore> Yeah it should be a bit simpler
22:46 < jtanx> thanks
22:47 < jtanx> see you tomorrow (probably)
22:48 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
23:28 -!- Callum_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Fri Sep 13 2013
08:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:31 < jtanx> oh yeah, I forgot to restart the bot :P
08:31 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
08:53 < sam_moore> So, using 2 FILE* causes some problems, I recommend we just use 1
08:54 < sam_moore> In theory the operating system is supposed to use locks when multiple processes have access to the same file
08:54 < sam_moore> But... 
08:54 < sam_moore> It probably doesn't work with threads
08:55 < sam_moore> I'm not sure exactly what goes wrong, but using 1 works and isn't really going to be slower (if the OS uses locks then that probably has a similar overhead to using a mutex)
08:59 < jtanx> yeah, let's stick to one then
09:00 < jtanx> there's still a few bugs around I think
09:00 < sam_moore> Probably
09:01 < sam_moore> I put valgrind back in, I got rid of a lot last night
09:01 < jtanx> nice
09:01 < sam_moore> Although I probably introduced them in the first place
09:01 < jtanx> what was with that mem leak in fastcgi code?
09:03 < sam_moore> Oh, that wasn't a memory leak, it was an uninitialised value
09:04 < sam_moore> I thought I'd be clever and use sizeof() on the FCGIValue array
09:04 < sam_moore> But I forgot that the actual number of elements is not just sizeof()
09:04 < sam_moore> It's sizeof(array) / sizeof(element)
09:04 < jtanx> oh right haha
09:05 < sam_moore> So the refactored code basically does the same thing
09:05 < sam_moore> But hopefully it's a bit cleaner
09:05 < jtanx> yep
09:05 < jtanx> it's pretty good
09:06 < jtanx> when you get an invalid id or format, do you want to reject that? 
09:07 < sam_moore> Yeah, I wasn't sure what I should do there, but I think Sensor_Handler is the only place you can really deal with that
09:07 < jtanx> yeah
09:07 < sam_moore> I did have it calling FCGI_RejectJSON if the sensor id was invalid
09:08 < jtanx> the current code on git just calls Log
09:08 < sam_moore> But I must have done something wrong, because the normal JSON was getting printed just after that
09:08 < sam_moore> So I removed it
09:08 < jtanx> oh yeah
09:08 < jtanx> you have to return after FCGI_RejectJSON
09:08 < sam_moore> Ah
09:08 < sam_moore> Durr
09:08 < jtanx> :P
09:09 < jtanx> anyways I'll look through and see if I can fix stuff up
09:09 < jtanx> then I'll try and do that start/stop stuf
09:10 < sam_moore> Ok
09:10 < sam_moore> I put in Sensor_Start and Sensor_Stop which might help
09:10 < sam_moore> I thought you might want to pause data collection without actually "stopping" the experiment?
09:11 < jtanx> ok
09:11 < jtanx> that might be a good idea
09:11 < sam_moore> And also it should be fairly easy to implement a Sensor_Load if we want to be able to load previous experiments
09:11 < jtanx> yeah
09:38 < jtanx> those issues with fread
09:38 < jtanx> it could be because you didn't specify the 'b' flag in fopen
09:38 < jtanx> ?
09:39 < jtanx>  // Clear the FILE*s
09:39 < jtanx>  df->read_file = NULL;
09:39 < jtanx>  df->write_file = NULL;
09:39 < jtanx>  fclose(df->write_file);
09:52 < sam_moore> Oh... hurdur
09:52 < sam_moore> Wait how is it working at all
09:52 < sam_moore> The write file is mode "w+" which should make it plain text
09:53 < jtanx> so it's no longer a binary file?
09:53 < jtanx> I think i may not be experiencing the same issues as you just because I'm running everything on single core processors
09:53 < sam_moore> Well... it certainly looks like a binary file when you try and cat it
09:53 < jtanx> ok
09:53 < jtanx> it's probably a good idea to stick to one file pointer and use mutexes
09:53 < sam_moore> Yeah
09:53 < sam_moore> But also make sure that file is binary
09:53 < jtanx> yeah
09:54 < sam_moore> It's probably compiler specific what happens when you use fwrite and fread on a plain text file
09:54 < jtanx> probably
09:54 < sam_moore> But it looks like a binary file to me, so I'm not sure that's related to the problems with fread
09:54 < sam_moore> I can investigate this by changing like 4 characters...
09:55 < jtanx> one thing I did notice on linux
09:55 < jtanx> if it wasn't a binary file you'd have to use fflush to explicitly write out text and have it appear when you used cat
09:56 < jtanx> but overall I think it's not due to it being a binary file or not
09:56 < sam_moore> Yep
09:56 < sam_moore> I just put the second FILE* for read_file back in
09:56 < sam_moore> Made them both binary
09:56 < sam_moore> Still get the "Transport endpoint is not connected" errors
09:57 < sam_moore> So there should be a "b" in the file mode, but that's unrelated to having multiple FILE*
09:57 < jtanx> yep then I think that's due to you running it on a multicore processor
09:57 < jtanx> maybe
09:57 < sam_moore> I think the OS locks around file access are based on PID
09:58 < jtanx> on linux all file locks are advisory only
09:58 < sam_moore> Can
09:58 < sam_moore> Anyway, it's clearly safest to just have one FILE*
09:58 < jtanx> yeah
09:58 < jtanx> I'm changing it now
10:09 < jtanx> oh ffs that's the second time it's crashed simply because I didn't do make clean before make
10:16 < sam_moore> haha
10:17 < sam_moore> Modify the make file to always run make clean?
10:28 < jtanx> haha that's one option
10:28 < jtanx> it's because make doesn't consider changes to the header files
10:28 < jtanx> there's a way to make it detect those, but *effort*
10:40 < sam_moore> Regarding Actuators, I think if we design for a thread to control (one or more) actuators that will make it easy to add more advanced control later
10:42 < sam_moore> eg: The Actuator_Handler just sets some kind of formula or says "Every time sensor 0 is stable for Xs (within a range) change actuator by Y" and the thread watches the sensor data and changes the actuator when necessary
10:43 < sam_moore> You could also add feedback that way too
10:44 < sam_moore> "Set this actuator so that sensor 0 has value X"
10:46 < jtanx> hmm
10:47 < jtanx> about the sensor stuff
10:47 < jtanx> there were a few things I noticed
10:48 < jtanx> the time wrapping 
10:48 < jtanx> could still give a negative start_time or end_time
10:48 < jtanx> if the user specified a very negative start_time/end_time
10:49 < jtanx> (eg specifies a negative time greater than the total running time)
10:49 < sam_moore> Oh yeah
10:49 < jtanx> so in data_printbytimes
10:49 < jtanx> I just clamped it to zero
10:49 < jtanx> instead of asserting
10:49 < sam_moore> Fair enough
10:49 < jtanx> strangely this code seems to work pretty good:
10:49 < jtanx> void Data_PrintByTimes(DataFile * df, double start_time, double end_time, DataFormat format)
10:49 < jtanx> {
10:49 < jtanx>  assert(df != NULL);
10:49 < jtanx>  //Clamp boundaries
10:49 < jtanx>  if (start_time < 0)
10:49 < jtanx>          start_time = 0;
10:50 < jtanx>  if (end_time < 0)
10:50 < jtanx>          end_time = 0;
10:50 < jtanx>  int start_index = 0, end_index = 0;
10:50 < jtanx>  if (start_time < end_time)
10:50 < jtanx>  {
10:50 < jtanx>          start_index = Data_FindByTime(df, start_time, NULL);
10:50 < jtanx>          end_index = Data_FindByTime(df, end_time, NULL);
10:50 < jtanx>  }
10:50 < jtanx>  Data_PrintByIndexes(df, start_index, end_index, format);
10:50 < jtanx> }
10:50 < jtanx> oh but that was the other ting
10:50 < jtanx> it works better if you have exclusive end index/time
10:50 < sam_moore> Ok
10:50 < sam_moore> I have to go now
10:50 < jtanx> ok
10:50 < sam_moore> See you this afternoon if you're still there
10:50 < jtanx> yep see you then
10:51 < jtanx> probably
10:58 -!- jtanx [[email protected]] has quit [Connection reset by peer]
13:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:44 -!- callum [[email protected]] has joined #mctxuwa_softdev
13:44 < callum> should i just add the sensor threshold values to the sensor struct?
13:47 < jtanx> probably not
13:47 < jtanx> I think you have to create a new struct
13:48 < jtanx> are you at uni?
13:49 < callum> yea. why is a new struct necessary? 
13:49 < jtanx> come to g19
13:49 < jtanx> the bbb is setup too
14:03 -!- callum [[email protected]] has quit [Connection reset by peer]
16:17 < sam_moore> Are you guys still in G19?
16:17 < sam_moore> On my way now
17:30 -!- jtanx [[email protected]] has quit [Ping timeout]
18:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:42 < jtanx> lol you need to use a transistor to turn on an led from the gpio pins
19:56 < jtanx> ok I think I'll just escape all input parameters from within the request loop
19:56 < jtanx> then at least you're guaranteed that user input won't stuff up anything
19:56 < jtanx> (as in making it generate invalid JSON)
20:53 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Sat Sep 14 2013
09:58 -!- MctxBot [[email protected]] has quit [Ping timeout]
11:08 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
11:32 < sam_moore> blergh, too many different versions of OpenCV
11:32 < sam_moore> Also too many different data types
11:33 < sam_moore> "Getting a digital image into numbers can be very handy for your image processing. In this post i will brief just that."
11:34 < sam_moore> Thank god, finally a tutorial that makes sense
11:34 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
11:34 < sam_moore> ... no one else is in the channel
11:34 < sam_moore> :S
11:37 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
12:36 < jtanx> on start/stop/pausing an experiment
12:36 < jtanx> currently everything is relative to g_options.start_time
12:42 < sam_moore> Yeah
12:43 < sam_moore> Perhaps make an ExperimentTime function and that leaves us free to change what the time stamps are relative to?
12:43 < sam_moore> Looking into this interferometer stuff...
12:43 < jtanx> ok, maybe as part of the Control_ module then
12:43 < sam_moore> Interesting problem, I think I've worked out an algorithm that isn't too terrible
12:44 < jtanx> yeah?
12:44 < jtanx> how does it work
12:45 < sam_moore> If you have a sinusoidal wave, find the x intercepts, and that lets you calculate the phase and frequency
12:45 < sam_moore> That's the simple version
12:46 < jtanx> haha alright
12:46 < sam_moore> I have 3 pages of notes that I can show Adrian/Adam if I can't get it working
12:46 < jtanx> wow
12:46 < jtanx> nice work
12:47 < sam_moore> Fortran would be good for the array operations
12:47 < sam_moore> If fortran were able to do anything *other* than array operations it would be a nice language...
12:47 < jtanx> have you ever used Fortan before?
12:48 < sam_moore> Yes
12:48 < sam_moore> I'm going to keep it in C though
12:48 < sam_moore> It took long enough to get OpenCV working
12:48 < sam_moore> I'm sure there's some kind of convoluted Fortran library
12:49 < sam_moore> But a seperate fortran program won't talk to our server
12:49 < jtanx> can you compile the code as a library with C interop
12:49 < sam_moore> Erm..
12:49 < sam_moore> Probably more effort than just doing it in C
12:49 < jtanx> probably
12:51 < jtanx> I think a separate mutex is needed around the *_Stop() functions
12:51 < jtanx> because if a client sends in a request
12:51 < sam_moore> Oh, good point
12:52 < jtanx> although that's only going to be a problem if our own software calls the stop function because of the sanity checks
12:52 < sam_moore> If there are 2 requests?
12:52 < sam_moore> No wait, the FCGI stuff is serial
12:52 < jtanx> the request loop is single threaded
12:52 < sam_moore> It has to finish processing one request to respond to the next
12:52 < sam_moore> That's fine
12:56 < sam_moore> Put a mutex in the Sensor struct, use the same one that's already in the Actuator struct, put critical sections around setting the "s->record_data" or "a->activated" variables (or whatever you choose to use as a "is thing running" flag)
12:56 < sam_moore> And check the flag hasn't already been set before doing anything
12:57 < sam_moore> Similar to how the Thread_Running() and Thread_QuitProgram() functions used to work
12:57 < sam_moore> .... Before I deleted them
12:57 < sam_moore> Any thread could call Thread_QuitProgram, and repeated calls would have no effect
13:01 < jtanx> ok I'll try that
13:51 < jtanx> actually, what about this:
13:51 < jtanx> in control.c, it maintains its own mutex
13:51 < jtanx> so
13:52 < jtanx> and it's the only place where Sensor_Start/Stop Actuator_Start/Stop is called
13:53 < jtanx> You then have Control_Lock/Unlock that's placed around the responses in the handler functions
13:53 < jtanx> those functions internally lock/unlock the mutex held in control.c
13:53 < jtanx> ah stuff it
13:53 < jtanx> I'll commit it to my git repo
13:54 < jtanx> I still don't know how the pause functionality should be done though
13:54 < jtanx> especially with the time discontinuities
14:01 < jtanx> oh yeah, just a reminder that you have to be careful using FCGI_LONG_T vs FCGI_INT_T
14:02 < jtanx> if your variable is of type int but you give FCGI_LONG_T, and where sizeof(int) != sizeof(long) then there could be a buffer overflow
14:13 < sam_moore> Right
14:14 < sam_moore> If you want to commit to the main repo you can use a new branch
14:14 < sam_moore> Having a single mutex in control.c instead of one per sensor/actuator is probably better
14:15 < sam_moore> With the pause functionality... I think if you just don't call Data_Close() (and don't call Data_Open on resuming) but otherwise stop the threads running Sensor_Loop in the same way
14:15 < sam_moore> That should do most of it
14:16 < sam_moore> Don't reset the experiment start time
14:17 < sam_moore> Perhaps the experiment start time needs to be stored somewhere though
14:18 < sam_moore> Anyway, I'll let you solve the problem :P
14:48 < jtanx> ._.
15:45 < jtanx> well I think I got something semi-working
15:45 < jtanx> it involved adding on Sensor_PauseAll/ResumeAll + Acuator_PauseAll/ResmueAll (plus the individual Pause/Resume) functions
15:46 < sam_moore> Cool
15:46 < sam_moore> I think I'm starting to get my head around OpenCV
15:46 < sam_moore> The documentation for it is a bit crap
15:46 < jtanx> oh don't get me started on opencv documentation
15:47 < jtanx> yesterday it took me and callum around 30  mins to figure out that CvMat structure
15:47 < sam_moore> Haha
15:47 < sam_moore> It probably took me a bit longer :S
15:47 < jtanx> the problem is that most of it's geared towards c++ usage
15:49 < jtanx> back on that control stuff, basically those Sensor/Actuator_[Start|Stop|Pause|Resume] functions can only be called via the Control_[Start|Stop|Pause|Resume] functions
15:50 < jtanx> partly because of threading issues but also because it's the only place where the current state is currently kept track of
15:51 < jtanx> (e.g if you call Sensor_Start twice then...
15:53 < sam_moore> Seems sensible
15:53 < jtanx> anyway, I'm taking a break from this stuff for a while
15:53 < sam_moore> Yeah, fair enough
15:54 < jtanx> If you want to see what I've done so far, it's on my git repo (haven't added comments yet)
15:54 < sam_moore> Cool
16:50 < sam_moore> The IplImage vs CvMat conversion is dumb
16:50 < sam_moore> In fact I don't think you even need to do it?
16:51 < sam_moore> Well at least to display an image you can just pass a CvMat
16:51 < sam_moore> Maybe you still need the IplImage to capture from a camera
16:51 < sam_moore> I worked out how to convert from IplImage to CvMat anyway
16:53 < sam_moore> Other than that, OpenCV doesn't actually seem horrible to use
16:53 < sam_moore> Just... contradictory documentation
16:55 < sam_moore> Anyway... I've created a moving sinusoidal image!
16:56 < sam_moore> Now to work out why the algorithm keeps returning -nan :S
16:56 < sam_moore> Also for some reason the image is blue instead of red
16:56 < sam_moore> But whatever
16:57 < jtanx> :S
16:57 < jtanx> BGR vs RGB?
17:02 < sam_moore> Looks like it
17:03 < sam_moore> Doing this with an actual camera is going to suck
17:04 < sam_moore> See, I've worked out an algorithm to cope with changing background light conditions
17:04 < sam_moore> Because differentiating a sinusoid gives you another sinusoid with the same phase (offset by pi/2)
17:05 < sam_moore> Buut... differentiating with finite differences adds more noise
17:05 < sam_moore> Or rather it makes the noise more pronounced
17:07 < sam_moore> Hopefully sensors is considering this
17:07 < sam_moore> If they want to shoot a laser into a camera, they should really do it in a way that keeps out background light
17:07 < sam_moore> Buuut
17:07 < sam_moore> I think they mentioned using one camera to do both the interferometer and look at the can
17:07 < sam_moore> :S
17:08 < sam_moore> Oh well, the optics is their problem
17:09 < sam_moore> I suppose I will prepare a report or something about the algorithm and what conditions the image needs to satisfy
17:12 < jtanx> um
17:12 < jtanx> there's going to be two cameras
17:12 < jtanx> because it was too much hassle moving it
17:12 < sam_moore> Yes... but one was meant to be looking at each can?
17:13 < jtanx> oh
17:13 < jtanx> hmm
17:13 < sam_moore> We should ask them
17:13 < jtanx> I just thought that one would be for the interferometer (no need to look at can) and the other would be for the can to be blown up
17:13 < sam_moore> Probably
17:15 < jtanx> but I was thinking for the one to be blown up
17:16 < jtanx> you could possibly just stream it using something like ffserver
17:16 < jtanx> instead of passing it through opencv
17:16 < sam_moore> Yeah, that seems like it's probably easier
17:23 -!- jtanx [[email protected]] has quit ["my antivirus is pestering me to restart"]
17:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:19 < sam_moore> So... when you take an image with a camera the pixels are stored as rgb with 0->255 values
18:20 < sam_moore> You can convert the IplImage to a CvMat and it keeps the values ordered as rgb with 0->255 values
18:20 < sam_moore> And then...
18:20 < sam_moore> If you try and display it...
18:20 < sam_moore> The display function treats it as having values in bgr order with 0->1 values
18:20 < sam_moore> -_-
18:21 < sam_moore> (So unless you manually adjust all the values you'll just get a white picture in the display)
18:54 < jtanx> hahaha
18:54 < jtanx> what
18:56 < jtanx> for cvShowImage:
18:56 < jtanx>         If the image is 8-bit unsigned, it is displayed as is.
18:56 < jtanx>         If the image is 16-bit unsigned or 32-bit integer, the pixels are divided by 256. That is, the value range [0,255*256] is mapped to [0,255].
18:56 < jtanx>         If the image is 32-bit floating-point, the pixel values are multiplied by 255. That is, the value range [0,1] is mapped to [0,255].
18:57 < jtanx> so it's treating it as 32-bit floating point?
19:49 -!- jtanx [[email protected]] has quit [Ping timeout]
19:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
20:41 < sam_moore> I think it's because of how I converted the IplImage to a CvMat
20:42 < sam_moore> My algorithm is almost working
20:43 < sam_moore> The fact that angles wrap around every 2*pi is giving me a headache though
20:43 < sam_moore> This is pretty fun
20:45 < sam_moore> Hopefully I can do Computer Vision as an optional, I think its in the list
20:45 < sam_moore> Maybe I shouldn't make all my optionals CS units, but meh
21:20 < jtanx> :P
21:20 < jtanx> the computer vision unit sounds interesting, but a lot of maths/theory involved
22:02 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Sun Sep 15 2013
09:13 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:02 < sam_moore> I'm really glad I put the IRC logs under git
11:02 < sam_moore> It's very helpful for keeping my diary up to date
11:40 < jtanx> hehe
11:40 < jtanx> I'm gladful for git
11:48 < jtanx> about the bbb
11:48 < jtanx> it's probably best to just install debian to the internal memory
11:54 < jtanx> on the controls
11:54 < jtanx> maybe we can have the following states: start/pause/resume/stop/close
11:56 < jtanx> actually, maybe just start/pause/resume/close
11:56 < jtanx> when an 'emergency stop' due to the sanity checks occurs
11:57 < jtanx> actually, start/pause/resume/close/emergency
11:57 < jtanx> start/pause/resume/close can only be initiated by the client
11:58 < jtanx> emergency can be initiated by client/server
11:58 < jtanx> in emergency, actuators are set as necessary then deactivated
11:58 < jtanx> but importantly, the data files remain open, which hopefully removes the need for mutexes
12:26 < sam_moore> That seems sensible
13:20 < sam_moore> Hey
13:20 < sam_moore> It's actually quite simple to stream an image through FastCGI
13:21 < jtanx> yeah
13:21 < jtanx> you just fwrite the image buffer
13:21 < sam_moore> Yep
13:21 < jtanx> I had some test code for that but could never test it
13:22 < jtanx> no webcam
13:22 < sam_moore> Ah, damn
13:22 < sam_moore> I've written some code, it works pretty brilliantly
13:22 < jtanx> nice
13:22 < jtanx> this control code is really annoying me
13:23 < jtanx> just all the considerations of if you need a mutex here or not and 'what happens if...'
13:23 < sam_moore> Ah, sorry to hear that
13:23 < jtanx> yeah nah its ok
13:24 < jtanx> but that interferometer stuff you did looks really cool
13:26 < sam_moore> Yeah, it worked surprisingly well
13:26 < sam_moore> It can cope with a fair bit of background light, even without all the improvements I was thinking about
13:27 < sam_moore> If I add 2 or 3 more columns to scan, and use the fact that we actually know the spatial frequency to eliminate nodes that are too close together
13:27 < sam_moore> It should be pretty good
13:27 < sam_moore> I'm not sure what the laser intensity will be, but the generated image looks similar to ones you can find on the internet
13:28 < sam_moore> One possible problem is if the mirrors aren't flat enough
13:28 < sam_moore> But hopefully it won't be a big issue (since they've pretty much just specified an expensive pre-built kit which presumably has flat mirrors)
13:29 < jtanx> yeah
13:30 < jtanx> here's to hoping 'it just works'
13:30 < sam_moore> Yep :P
13:31 < sam_moore> Got to go, bye
13:32 < jtanx> ok cya
15:50 -!- jtanx [[email protected]] has quit [Ping timeout]
15:56 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
15:56 -!- jtanx_ is now known as jtanx
21:48 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Mon Sep 16 2013
07:28 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:27 -!- jtanx [[email protected]] has quit [Ping timeout]
12:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:05 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
16:05 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
16:10 -!- jtanx [[email protected]] has quit [Ping timeout]
19:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:44 < jtanx> no mctxbot while I work on my f# project
20:00 -!- MctxBot [[email protected]] has quit [Ping timeout]
21:26 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
22:58 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Sep 17 2013
08:14 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:50 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
15:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:34 < jtanx> to run the software not as root, we need to at least add it to the 'video' group so it can access the webcam
15:34 < jtanx> not sure about the sensors
15:34 < jtanx> eg sudo usermod -a -G video debian
15:38 < sam_moore> Ah, cool
15:39 < sam_moore> I think I worked out how to get around the camera crashing without killing the rest of the program, won't implement it for a while though
15:40 -!- MctxBot [[email protected]] has quit [EOF From client]
15:43 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
15:48 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
15:53 -!- jtanx [[email protected]] has quit [Ping timeout]
15:57 -!- jtanx_ is now known as jtanx
16:41 -!- jtanx [[email protected]] has quit [Ping timeout]
16:46 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
16:46 -!- jtanx_ is now known as jtanx
18:02 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
18:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:31 -!- MctxBot [[email protected]] has quit [Ping timeout]
22:38 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
22:49 -!- jtanx [[email protected]] has quit [Ping timeout]
23:17 -!- Callum [[email protected]] has joined #mctxuwa_softdev
23:18 < Callum> hey
23:23 < sam_moore> Hi
23:24 < Callum> do you know how to do the second question of that assignment?
23:24 < Callum> https://docs.google.com/file/d/0B241H5liqVlnbHZETXRZX1Mwd1k/edit?usp=sharing
23:25 < Callum> rather remember
23:35 < sam_moore> Well, you can eliminate any epsilon^2 when you substitute those formulae for v into the formula for gamma
23:35 < sam_moore> Then it has a really simple taylor expansion
23:35 < Callum> i might have to hunt you down tomorrow to show me. or maybe il be able to think straight tomorrow.
23:38 < sam_moore> You can express one of the epsilons in terms of the other one after that
23:40 < sam_moore> I'm pretty busy tomorrow
23:42 < Callum> mhmm. so no free time at all? coz im fairly free
23:49 < sam_moore> Not from 8:00am until 5:00pm
23:49 < Callum> ohwow. you are busy
23:49 < Callum> im still unsure what im meant to be applyign the taylor expansion to
23:53 < sam_moore> Substitute in the suggested formulae to gamma, simplify it, then apply a taylor expansion
23:53 < sam_moore> Anyway, goodnight, good luck
23:53 < Callum> night
--- Day changed Wed Sep 18 2013
00:07 -!- Callum [[email protected]] has quit [EOF From client]
07:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:11 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
18:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:04 -!- MctxBot [[email protected]] has quit [Ping timeout]
21:03 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
21:39 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
--- Day changed Thu Sep 19 2013
16:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:08 < jtanx> one thing I forgot to mention - the latest version on git uses syslog
16:08 < jtanx> if you copy the config file (server-configs/rsyslog.d/* ??) to /etc/
16:09 < jtanx> it will log to /var/log/mctx[something I can't remember].log
16:10 < jtanx> i'm pretty sure you can also create a log file specifically for warning level and above (so it logs in three places, stderr, the normal log, and a special 'error' log), but I haven't set this up yet
18:15 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
18:17 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
18:17 < jtanx_> :0
18:22 < sam_moore> ?
18:30 -!- MctxBot [[email protected]] has quit [Ping timeout]
18:31 -!- jtanx [[email protected]] has quit [Ping timeout]
18:50 -!- jtanx_ is now known as jtanx
19:11 -!- jtanx [[email protected]] has quit [Ping timeout]
19:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:52 -!- MctxBot_ is now known as MctxBot
20:24 < jtanx> I got the camera image to be updated in javascript instead: http://mctx.us.to:8080/test/
20:25 < jtanx> right now it's updated around every ~400ms because my webcam is running through a usb1.1 link which seriously limits how fast it can update
20:36 < jtanx> (its running on a pentium 3 computer)
21:35 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Fri Sep 20 2013
15:38 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:53 -!- MctxBot [[email protected]] has quit [Ping timeout]
18:02 < jtanx> this seems like an interesting option, at least for the cam that just shows the can explode:http://sourceforge.net/apps/mediawiki/mjpg-streamer/index.php?title=Main_Page
18:51 < sam_moore> Cool
18:51 < sam_moore> It, ah
18:52 < sam_moore> Looks like we might have to recompile the kernel to get PWM working
18:52 < sam_moore> Hooray
18:52 < sam_moore> Kernel compiling
18:52 < sam_moore> What could possibly go wrong?
19:02 < jtanx> really??
19:02 < jtanx> why....
19:03 < jtanx> no am33xx_pwm module?
19:04 < sam_moore> Not that I can tell
19:05 < jtanx> well crap
19:06 < sam_moore> Well... surely I can find a precompiled kernel somewhere
19:06 < jtanx> it seems that stuff for the BBB is at a really premature stage
19:07 < sam_moore> Yeah, RPi is much nicer
19:07 < jtanx> the BBB is just too new..
19:07 < sam_moore> What's the point of having fancy things like ADC and PWM...
19:07 < sam_moore> If you can't actually use them without jumping through hoops
19:07 < jtanx> hahaha
19:07 < jtanx> were you referencing this, when you said we might have to recompile the kernel? https://groups.google.com/d/msg/beagleboard/wjbOVE6ItNg/AGYVRhYbTX8J
19:08 < sam_moore> Yeah
19:08 < sam_moore> ...
19:08 < sam_moore> I wonder if I can take the kernel used by Angstrom and stick it in /boot
19:08 < sam_moore> on the SD card
19:09 < jtanx> ._.
19:10 < jtanx> what about kernels from here
19:10 < jtanx> http://rcn-ee.net/deb/precise-armhf/
19:10 < jtanx> sorry
19:10 < jtanx> http://rcn-ee.net/deb/wheezy-armhf/
19:11 < jtanx> what's it currently running
19:12 < sam_moore> 3.8.13-bone20
19:13 < sam_moore> Try 3.8.13-bone28 ?
19:15 < jtanx> what about v3.8.9-bone15
19:15 < jtanx> oh wait
19:15 < jtanx> ~.~
19:15 < sam_moore> I wonder why the BBB developers didn't go with debian...
19:15 < jtanx> v3.11.0-bone5
19:15 < jtanx> yeah
19:15 < jtanx> why angstrom, of all things
19:15 < sam_moore> Is angstrom used anywhere else?
19:16 < jtanx> dunno
19:16 < sam_moore> Other embedded devices, heh
19:16 < sam_moore> Everyone just has to use their own distro :P
19:17 < sam_moore> I didn't see the .11 kernels, I'll try the latest one
19:17 < jtanx> want to try the rc version? lol
19:18 < jtanx> oh the rc versions are older than .11
19:19 < jtanx> how does it work?
19:19 < jtanx> do you just download from http://rcn-ee.net/deb/wheezy-armhf/v3.11.0-bone5/
19:19 < jtanx> the .sh script and run it from the BBB?
19:24 < sam_moore> I think so
19:25 < sam_moore> Well... here goes nothing
19:26 < sam_moore> Hopefully between 3.8 and 3.11 they actually enabled PWM by default...
19:27 < sam_moore> It looks like install-me.sh downloads all the .deb files appropriately
19:29 < sam_moore> It's creating files like: /lib/firmware/bone_pwm_P8_36-00
19:29 < sam_moore> Which looks promising
19:29 < sam_moore> Snoopy is not yet on fire
19:29 < sam_moore> Which is promising
19:29 < sam_moore> Rebooting and praying
19:31 < sam_moore> And... it booted into 3.8.13-bone20 -_-
19:31 < sam_moore> Tempted to just symlink that filename to the new kernel
19:34 < sam_moore> The new kernel exists in /boot, but obviously there's some boot config that needs to get set
19:39 < sam_moore> Ok, screw this, I'm making a symlink just to see if it works
19:40 < jtanx> lol
19:41 < jtanx> no grub
19:43 < jtanx> did update-initramfs run?
19:46 < jtanx> or maybe we need mkimage
19:47 < jtanx> yeah probably need mkimage
19:50 < sam_moore> Um, zImage is a symlink to the kernel
19:50 < sam_moore> But regardless, the new one won't boot
19:50 < sam_moore> Such a pain
19:50 < sam_moore> I wonder if we can just toggle the GPIO pin fast enough to implement PWM
19:56 < sam_moore> Using a decent oscilloscope, I read a 6us period when switching GPIO1_28 on/off as fast as possible
19:59 < sam_moore> That
19:59 < sam_moore> s like 166KHz
19:59 < sam_moore> Heh
19:59 < sam_moore> Maybe the sources you found were closing the file and reopening it?
20:01 < sam_moore> Yeah, wow
20:02 < sam_moore> Using fopen, fprintf and fclose each time takes the period to 224us
20:02 < sam_moore> Or 4KHz
20:03 < sam_moore> Also for future reference, that CRO in G19 is definitely broken; it's always a lovely square wave on the modern oscilloscope I'm testing with now
20:12 < jtanx> haha ok
20:13 < jtanx> but without kernel support your pwm signal won't be very accurate
20:13 < sam_moore> Yeah, I suppose
20:13 < jtanx> how come the new kernel won't boot?
20:14 < sam_moore> No idea
20:14 < jtanx> Hmm
20:14 < jtanx> this lack of documentation on how you do such procedures is pretty crap
20:15 < sam_moore> Yeah, kernel developers aren't great on documentation
20:15 < jtanx> is the mkimage package present?
20:15 < jtanx> if not, install it and try running the install-me script again
20:16 < jtanx> from this: http://www.jeremycole.com/blog/2011/03/09/beagleboard-upgrading-from-debian-5-to-debian-6/
20:16 < jtanx> it should be just running that install script and rebooting
20:16 < sam_moore> Alright, uboot-mkimage I presume?
20:16 < jtanx> i guess
20:17 < jtanx> and update-initramfs?
20:18 < jtanx> (just looking at what the install-me.sh script uses)
20:18 < sam_moore> Oh, does the script not fail if packages it needs don't exist...
20:18 < sam_moore> -_-
20:19 < jtanx> a quick scan says nup
20:24 < sam_moore> Already had initramfs-tools but not mkimage, so I'll try again
20:27 < sam_moore> I should probably have focused on the ADC reading before PWM
20:27 < sam_moore> We're definitely going to get asked about aliasing again
20:28 < jtanx> urgh yeah
20:28 < sam_moore> I don't have a signal generator here though
20:28 < jtanx> this BBB has definitely not been designed with 'plug n play' in mind
20:28 < sam_moore> Mmm
20:29 < sam_moore> The Angstrom image would work for this stuff, but obviously has limitations in terms of the webserver stuff
20:29 < sam_moore> But even with Angstrom you still have to go through a similar convoluted process to control pins
20:30 < sam_moore> From what I can tell there are two ways to do it
20:30 < sam_moore> SYSFS, which I can't find much documentation on
20:30 < sam_moore> Which is the /sys/class/gpio/ stuff
20:30 < sam_moore> Which actually seems more intuitive than the other way
20:31 < sam_moore> That involves echoing a bunch of cruft to /sys/devices/cape-manager/slots/ or something similar
20:31 < jtanx> hmm
20:32 < sam_moore> There is a /sys/class/pwm
20:32 < sam_moore> But unfortunately whatever you export it complains about
20:32 < sam_moore> Probably because the kernel wasn't compiled with it enabled
20:32 < jtanx> is this with the old kernel?
20:32 < sam_moore> Yeah
20:33 < sam_moore> Hangon, the new one's probably finished building by now
20:34 < jtanx> we don't know if the new one has been compiled with pwm support though
20:34 < sam_moore> Yeah
20:36 < sam_moore> The diff between the config options for the kernels shows that the old one has a comment "CONFIG_EHRPWM_TEST is not set" and the newer one has no reference to it
20:37 < sam_moore> ...
20:37 < sam_moore> Someone at some point
20:37 < sam_moore> Has realised that PWM was not enabled
20:37 < sam_moore> And commented that it isn't enabled
20:37 < sam_moore> WHY THE HELL DIDN'T THEY JUST ENABLE IT
20:37 < jtanx> :P
20:37 < sam_moore> Anyway it still booted off the old kernel
20:37 < sam_moore> Dinner time
20:38 < jtanx> ok
20:57 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
21:15 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
21:15 < sam_moore> Looks promising
21:16 < sam_moore> Hmm...
21:17 < sam_moore> I'll try using 3.8 but building with the PWM
21:18 < jtanx> building from source - fun fun :P
21:19 < sam_moore> Well in theory I just change a config option
21:19 < jtanx> yeah
21:19 < sam_moore> When that doesn't work and I have to modify the source, that's when the fun begins
21:19 < jtanx> let's just hope it works
21:19 < sam_moore> Yeah, if it doesn't we're (beagle) boned
21:19 < jtanx> oh while you're at it, figure out how to enable the ethernet-over-usb feature
21:19 < sam_moore> Haha
21:20 < jtanx> loljk
21:25 < sam_moore> Hmmm... compiling a kernel is going to take a while
21:26 < sam_moore> Ergh, why am I running it on this Pentium D
21:30 < sam_moore> Hmmm, more troubling... why does a debian wheezy server have OpenSUSE sources in sources.list
21:30 < sam_moore> Oh well, not my problem
21:33 < jtanx> heh
21:33 < sam_moore> How the hell are we going to explain this in the progress report...
21:34 < sam_moore> Also, I didn't fully understand, why can't you use the same image for multiple BBB?
21:34 < sam_moore> Are we going to have to do this all again for the other BBB?
21:34 < sam_moore> Spike I mean
21:37 < jtanx> no idea
21:38 < jtanx> without some sort of debugging cable to see what happens when it boots, who knows
21:38 < sam_moore> :S
21:39 < sam_moore> I love how git gets to the head of the branch
21:39 < sam_moore> By starting at the initial commit
21:39 < sam_moore> And going through every commit and changing the file
21:42 < sam_moore> It hasn't started building yet
21:42 < sam_moore> And the way you customise the build...
21:42 < sam_moore> Is to build it with the defaults, so that the options file exists, then change the options, then build it again -_-
21:43 < jtanx> ಠ ಠ
21:43 < sam_moore> Oh well, I have to go home, I'll try finish this tomorrow
21:43 < sam_moore> Bye
21:43 < jtanx> ok
21:43 < jtanx> bye
23:20 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sat Sep 21 2013
08:42 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:23 < sam_moore> http://hipstercircuits.com/enable-pwm-on-beaglebone-with-device-tree-overlays/
11:23 < sam_moore> So... according to this I should add pwm_test as a kernel module
11:24 < sam_moore> "This is it. It is now three o’clock in the morning and I have not slept or eaten in two days. My neck is sore, my ass has fallen asleep and my organs are screaming “slow down, man”. I no longer see [CC]s, [LD]s and [AS]s, I only see blondes, brunettes and redheads flashing before my eyes. With my last ounce of energy I barely manage to type in “reboot” as my face hits the keyboard. And that is when it happens.."
11:25 < sam_moore> Ummm
11:25 < sam_moore> It's awesome that this guy has solved the problem (I think)
11:26 < sam_moore> But a bit depressing that it still isn't in the official kernel
11:29 < sam_moore> I think most people just give up and use Angstrom, which is tempting
11:30 < sam_moore> I still have that HTTP server code... :P
11:45 < sam_moore> Looks like Robert C Nelson's 3.8 kernel does have a pwm_test module
11:45 < sam_moore> Maybe the image you used just had an out of date kernel?
11:45 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
11:51 < jtanx> hmm
11:51 < jtanx> no idea
11:51 < jtanx> it was made in july I think and it uses those rcn kernels
11:51 < jtanx> We could always use lighttp
11:51 < jtanx> lighttpd on angstrom if necessary
11:52 < jtanx> lighttpd and install mod_fastcgi
11:55 < jtanx> ok so the image uses 3.8.13-bone20, so maybe it wasn't enabled in that version, but it now is in 3.8.13-bone28?
12:02 < sam_moore> I've just built 3.8.13-bone28 and the module pwm_test exists
12:03 < sam_moore> ... I also copied the code from that guy's blog as pwm_test2 just in case :P
12:03 < sam_moore> I'll have to test it later, but at least we have the kernel module
12:08 < jtanx> nice
12:39 < jtanx> ohhhhh I know why it didn't work from one bbb to the next, using the same image
12:39 < jtanx> When you boot for the first time, it assigns the ethernet port eth0
12:39 < jtanx> when you then take it out and boot it on a different BBB
12:40 < jtanx> because the ethernet device has a different id, it gets assigned to say eth1
12:40 < jtanx> and because you don't have any config for eth1 in your network config, there's no internet access
12:40 < jtanx> http://www.eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-Networking:UsingasharedSDcardwithMultipleBeagleBone
12:41 < jtanx> should fix that
13:21 -!- jtanx [[email protected]] has left #mctxuwa_softdev []
13:21 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:10 < jtanx> Eh, you know what I'll just stop the threads when you want to pause it
15:10 < jtanx> instead of conditionals
15:11 < jtanx> it's not like you're pausing the experiment that often
15:18 < sam_moore> That's fine
15:19 < sam_moore> The conditional approach is only really necessary if you're constantly pausing the threads
15:19 < sam_moore> I used it for an nbody simulator, so the computation of force and position was split up between threads
15:19 < sam_moore> It's really slow if you have to stop and then recreate the threads on every step
15:22 < sam_moore> Although still actually faster than the single threaded program
15:22 < sam_moore> Well, depending on how many objects you simulated
15:23 < sam_moore> Anyway, just stop the threads, it's simpler to code and the performance effect in our case is probably negligable
15:30 < jtanx> yeah
15:30 < jtanx> say you had an actuator that was being controlled at that instant when an 'emergency stop' was issued
15:31 < jtanx> since an 'emergency stop' is the same as just pausing (eg stopping the thread but keep DataFile open)
15:31 < jtanx> you'd have to wait for that action to be completed before the 'emergency stop' would be propagated
15:34 < jtanx> welp I guess that's why there's hardware safety interlocks
15:38 < jtanx> Also, technically wouldn't it be possible to try to set the actuator value before the current value has been set
15:38 < jtanx> Since there's no queue
15:39 < jtanx> a->control could be overwritten by a new request as Actuator_SetValue operates
16:12 < sam_moore> We want that right?
16:13 < sam_moore> I'll look at it later if I get time
16:14 < jtanx> I don't know if we want that or not
16:15 < jtanx> wait want as in the current behaviour or the behaviour with a queue?
16:16 < sam_moore> The current behaviour
16:16 < sam_moore> I don't think you need a queue
16:16 < sam_moore> You can extend the critical section in Actuator_Loop to stop the current control getting overwritten
16:17 < sam_moore> Move the pthread_mutex_unlock on line 121 to below line 127 (Actuator_SetValue)
16:17 < sam_moore> That way if Actuator_SetControl is called before the value has been successfully set, it will just wait
16:17 < sam_moore> Mutexes actually implement a queue
16:18 < sam_moore> If one thread has a lock on the mutex, subsequent threads that try to access the mutex will queue up; whenever the mutex is unlocked the next thread (if any) which was waiting will get it
16:18 < jtanx> ok
16:23 < jtanx> I'll leave it as is for now
16:23 < sam_moore> Sure
16:49 < sam_moore> PWM working
16:49 < jtanx> nice
16:50 < jtanx> I still don't really understand - did you compile the kernel from scratch
16:50 < jtanx> or did you figure out how to use the install-me.sh script
16:50 < sam_moore> I did, but I didn't need to modify it
16:50 < jtanx> huh
16:50 < jtanx> ok
16:51 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
16:52 < jtanx> so if we do this: http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone
16:52 < jtanx> We should be able to just copy our image
16:52 < jtanx> and stick it on the electronics' BBB
16:53 < sam_moore> Sounds good
16:53 < sam_moore> I'm glad that worked
16:53 < jtanx> yeah
16:54 < jtanx> I wonder if it also enabled the usb0 stuff (ethernet over usb)
16:58 < sam_moore> PWM appears to have picosecond resolution? Or at least the arguments are in ps
17:02 < jtanx> oO
17:11 < sam_moore> ADC can sample at ~4KHz
17:11 < sam_moore> But... that's using bash
17:11 < sam_moore> It will probably be massively fast when done in C
17:11 < jtanx> um
17:11 < jtanx> is there any need to have it sample at a consistent rate
17:11 < jtanx> as in, with threads there's no guarantee
17:12 < jtanx> of a consistent sampling rate
17:12 < sam_moore> Yes, you're right
17:13 < sam_moore> I don't think we can achieve a consistent sampling rate, but I don't think it's critical that we do
17:14 < sam_moore> As soon as we make our software run in an operating system with a kernel and other processes that can run as well, it gets pretty unfeasable to have a constant sample rate
17:14 < sam_moore> We can have it constant to within an uncertainty I guess
17:15 < jtanx> yeah, true
17:18 < sam_moore> If you wanted a really high constant sample rate (say much faster than 1us which is probably the best case we could get) you'd have to use a more low level embedded device
17:18 < sam_moore> Well I guess you could compile your own kernel for the BBB
17:19 < sam_moore> But either way you'd have to physically run the webserver/GUI interface stuff on a seperate device
17:19 < sam_moore> At this stage my feeling is what we have is good enough given the complexity of all the requirements we were given
17:23 < jtanx> yeah
17:25 < sam_moore> Hmm, I can set some GPIO pins to toggle whenever Sensor_Read is called and get an idea of sample rates and to what degree of accuracy we can quote the time stamps
17:26 < sam_moore> I think I'll write some pin control code
17:26 < sam_moore> I don't trust any of these custom libraries
17:29 < jtanx> custom libraries?
17:36 < sam_moore> Well they aren't really libraries
17:36 < sam_moore> http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO#Example_of_GPIO_access_from_within_a_C_program
17:37 < sam_moore> Eg: That one has an fopen and fclose each time the value is changed
17:38 < sam_moore> I could google until I find someone that has already written a C library, but chances are it will be slow or broken
17:38 < sam_moore> Since I've worked out how to control the pins I may as well just write the C code to do it
17:39 < jtanx> yep
17:49 < sam_moore> I wonder if I can do this with a macro...
18:30 < sam_moore> Ergh, screw that
18:31 < sam_moore> Ok, I'm going to implement things like: GPIO/ADC/PWM_Export/Unexport to initialise or deinitialise all pins
18:31 < jtanx> Ok
18:31 < jtanx> too much effort with macros?
18:31 < sam_moore> Yeah, 
18:32 < sam_moore> I was thinking of having something like "GPIOX_Set()" instead of GPIO_Set(int x)"
18:32 < sam_moore> But that's probably not as nice as I thought it was
18:32 < sam_moore> Anyway, there's an enum in the header file that contains the id of all pins used
18:32 < sam_moore> The implementation defines some structs that wrap around the file descriptors
18:33 < sam_moore> But to use the module you just give it an ID as defined in the enums
18:33 < jtanx> Makes sense
18:33 < jtanx> designing the gui is actually not too bad
18:33 < sam_moore> That's good
18:34 < jtanx> looks ok in ie8 too
18:34 < sam_moore> Nice
18:35 < jtanx> gotta go, dinner
18:35 < sam_moore> Ok
18:35 < sam_moore> Hmm, it would be nice if C had value checking on enums
18:35 < sam_moore> You can define a function that takes an enum type as an argument
18:36 < sam_moore> But people can still just pass any old integer
18:36 < sam_moore> As far as I know
18:36 < sam_moore> eg: typedef enum {FIRST=1, SECOND=10, THIRD=100} EnumType
18:36 < sam_moore> void Foo(EnumType e);
18:37 < sam_moore> If you go Foo(2) it won't complain
18:38 < sam_moore> Annoying
18:38 < sam_moore> That seems like something the compiler would be able to pick up
19:31 < sam_moore> Ergh, I'm getting too obsessive compulsive with this pin thing
19:35 < sam_moore> It's annoying because ADC, GPIO and PWM are treated completely differently
19:35 < sam_moore> You write one thing and it enables *all* the ADCs
19:35 < sam_moore> You have to enable each GPIO pin individually
19:36 < sam_moore> And to enable PWM pins you give a string (not just an integer)
19:37 < sam_moore> Also the location of the pin files is not guaranteed (though it probably doesn't change for a given system configuration)
19:39 < sam_moore> Ah, I found a way to enable pwm with /sys/class/ instead of that cape manager thing
19:39 < sam_moore> I think I'll use that, since at least it's consistent with the GPIO stuff
19:41 < sam_moore> Ooh!
19:41 < sam_moore> http://beagleboard-gsoc13.blogspot.com.au/2013/07/sampling-analogue-signals-using-adc-on.html
19:41 < sam_moore> Provides a driver for continuously sampling with the ADC
19:41 < sam_moore> Oh wait
19:41 < sam_moore> Crap in a bucket
19:42 < sam_moore> Because we're using those multiplexers we can't do that
19:42 < sam_moore> We have to set the multiplexer before each sample
19:42 < sam_moore> Oh well, never mind
19:44 < sam_moore> I suppose we could write our own kernel module :S
19:45 < sam_moore> I think I understand this enough to talk to Adam next time he tries to talk about sample rate
19:46 < sam_moore> 1. It's not actually constant, but we can probably have it constant to within a few us
19:46 < sam_moore> 2. To make it constant would require writing a kernel module
19:47 < sam_moore> Unless electronics stops being stingy and gets one amplifier per channel :P
20:22 < jtanx> hehehe
20:22 < jtanx> next week's adrian though
20:22 < sam_moore> Ah
20:23 < jtanx> grilling time
20:23 < sam_moore> He'll probably ask us the same things :P
20:23 < jtanx> yeah
20:23 < jtanx> but man, so much stuff to go through just to get some readings from a few pins
20:24 < jtanx> so good job with that :P
20:54 < sam_moore> Thanks
22:45 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sun Sep 22 2013
00:51 < sam_moore> Hell yes
00:51 < sam_moore> PWM controlled through web browser
00:51 < sam_moore> GPIO controlled through web browser
01:19 < sam_moore> .... And ADC read through web browser
01:19 < sam_moore> Blergh
01:28 < sam_moore> I think I'll take the rest of today off from MCTX3420 :S
08:21 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:32 -!- jtanx [[email protected]] has quit [Ping timeout]
11:36 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:53 < sam_moore> I've analysed the crap out of sampling rates for this ADC
11:53 < sam_moore> At least as much as I can just using the timestamps according to gettimeofday
11:54 < sam_moore> Contrary to my first email, reading the ADC is actually really slow. And also probably the greatest source of variation in sampling rate.
11:56 < jtanx> wow
11:56 < jtanx> only 100Hz?
11:56 < sam_moore> Well it looks more like 1KHz on the oscilloscope, but there's a lot of variation, it has trouble getting a trigger
11:57 < jtanx> the cpu datasheet rates it at 200kSPS
11:57 < sam_moore> Hmm
11:58 < sam_moore> Well judging by the control it is something about the ADC reading that makes it really slow
11:58 < jtanx> That's annoyng
11:58 < sam_moore> Yeah
11:58 < sam_moore> Also annoying is that the ADC file is generally in a different place each time they're enabled
11:59 < sam_moore> I ended up modifying the program to take the path to the ADC file as an argument
11:59 < sam_moore> And making run.sh do the initialisation
11:59 < sam_moore> I figured that was better than calling system()
11:59 < jtanx> that makes sense
11:59 < sam_moore> Yep, we might want to set other options that run.sh can pass to it anyway
12:00 < sam_moore> Ok, I have to stop now, I'm spending way to much time on this
12:00 < jtanx> Haha
12:00 < sam_moore> It's getting to the point where I'm considering writing an ADC kernel module that doesn't suck :S
12:01 < jtanx> :S let's hope it doesn't get to that stage
14:08 -!- jtanx [[email protected]] has quit [Connection reset by peer]
14:25 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:37 -!- MctxBot [[email protected]] has quit [Ping timeout]
15:21 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
20:12 < jtanx> the pressure regulator has a 1-5vdc analogue output
20:12 < jtanx> is this considered one of the pressure sensors?
20:14 < jtanx> or maybe it's just not used
21:50 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Mon Sep 23 2013
07:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:51 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
19:38 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:41 -!- MctxBot [[email protected]] has quit [Ping timeout]
20:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
21:02 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
22:33 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
--- Day changed Tue Sep 24 2013
13:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:18 < jtanx> with kernel 3.8 they decided to make life hard with device tree overlays
14:19 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/277811.aspx
14:19 < jtanx> https://docs.google.com/a/beagleboard.org/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub
14:47 < jtanx> huh
14:47 < jtanx> http://www.youtube.com/watch?v=6gv3gWtoBWQ
14:47 < jtanx> http://digital-drive.com/?p=146
15:39 < sam_moore> I wonder if I can write a module that just uses /dev/adcX /dev/gpioX and /dev/pwmX
15:40 < jtanx> that would make life simple
15:40 < jtanx> but no
15:42 < sam_moore> http://www.tldp.org/LDP/lkmpg/2.6/html/x569.html
15:42 < sam_moore> Probably out of date (2.6?)
15:45 < sam_moore> Also rt.wiki.kernel.org - realtime linux supposedly gives you better timing accuracy, although it would possibly break with our setup involving nginx
15:46 < sam_moore> Actually it looks like there are quite a few ways for it to not work
15:48 < jtanx> I think trying to write a kernel module would cause more grief than it's worth
15:50 < jtanx> http://saadahmad.ca/using-pwm-on-the-beaglebone-black/
15:51 < jtanx> I have no idea what's been updated and what hasn't
15:51 < jtanx> as in, do we have that fix in our kernel
15:53 < sam_moore> I don't know
15:54 < sam_moore> We only need 1 PWM though
16:00 < sam_moore> Or at least, last we heard there was only one. Doesn't make the system very expandable though.
19:07 < jtanx> you know what I'll try loading an Ubuntu image from rcn to my sd card
19:08 < jtanx> instead of from armhf
19:08 < jtanx> armhf.com*
19:17 < jtanx> ah screw it
19:17 < jtanx> i'll stick with debian (but do the same thing)
21:07 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
21:34 -!- MctxBot [[email protected]] has quit [Ping timeout]
--- Day changed Wed Sep 25 2013
08:41 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
11:31 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
12:15 < jtanx> I think I know why we were having issues with pwm yesterday
12:16 < jtanx> if you do this command
12:16 < jtanx> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.8/slots
12:16 < jtanx> you make it unavailable from /sys/class/pwm
12:16 < jtanx> so in the run.sh script it was exporting all the pwm devices via the first method
12:16 < jtanx> and then it becomes unavailable via sysfs
12:17 < jtanx> anyway... I tried booting from the rcn image
12:17 < jtanx> it comes with pwm enabled already
12:17 < jtanx> and via that capemgr I got pwm to work
12:17 < jtanx> I don't know what /sys/class/pwm/pwm0 corresponds to (which pin)
12:19 < jtanx> the electronics teams' bbb wasn't done properly when we tried to upgrade the kernel
12:19 < jtanx> probably something to do with the device tree stuff
12:19 < jtanx> so I flashed it with the rcn image (which runs 3.8.13-bone26
12:20 < jtanx> (demo image from here)
12:20 < jtanx> elinux.org/BeagleBoardDebian
12:47 -!- jtanx [[email protected]] has quit [Ping timeout]
13:09 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
13:09 -!- jtanx_ is now known as jtanx
13:16 < jtanx> oh
13:16 < jtanx> so it now works
13:16 < jtanx>  echo bone_pwm_P9_22 > slots
13:16 < jtanx> if I do that line for pwm0
13:26 < jtanx> oh right
13:26 < jtanx> echo bone_pwm_P9_21 >slots 
13:26 < jtanx> for pwm1
13:30 < jtanx> ahhhhhh
13:30 < jtanx> if you comment out the line
13:30 < jtanx> modprobe pwm_test
13:30 < jtanx> from run.sh
13:30 < jtanx> it works
13:43 < jtanx> geeze kernel 3.8 has issues with usb hotplugging 
13:43 < jtanx> https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/usb/beagleboard/8aalvyWwaig/MUXAPuMTSOYJ
13:43 < jtanx> which explains why we're having issues with cameras
13:43 < jtanx> (partly at least)
13:47 < jtanx> and now pwms not working again
13:48 < jtanx> via sysfs
13:50 < jtanx> oh
13:50 < jtanx> I know why
13:51 < jtanx> you have to export it /sys/class/pwm
13:51 < jtanx> first
13:51 < jtanx> *before* you do stuff like       echo bone_pwm_P9_21 >slots 
13:52 < jtanx> yep 
13:53 < jtanx> so the order is: echo 0/1 > /sys/class/pwm/export
13:53 < jtanx> then do that other stuff
13:57 < jtanx> egh
13:57 < jtanx> finnicky
13:57 < jtanx> ok I have to stop now
14:14 -!- jtanx [[email protected]] has quit [Ping timeout]
14:15 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:46 -!- jtanx [[email protected]] has quit [Ping timeout]
16:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:04 < jtanx> well that was an interesting experience
16:04 < jtanx> it's most reliable when you work directly with /sys/devices/ocp2.helper/PWM9_22*
16:05 < jtanx> I think if you echo am33xx_pwm to the slots thing when it's already loaded
16:05 < jtanx> weird shit can happen
16:05 < jtanx> too
16:07 < jtanx> setting the period via sysfs (eg /sys/class/pwm) didn't work most of the time either
16:07 < jtanx> you could change duty but not period
16:07 < jtanx> although I swear I had it working at one point
16:07 < jtanx> via the other way I think it works ok
16:08 < jtanx> oh yeah, and I was doing this using the demo image from http://elinux.org/BeagleBoardDebian
16:09 < jtanx> the electrical group's one has been reflashed with that version as well
16:09 < jtanx> (for ours I worked off my sd card)
16:10 < jtanx> that image also enables the ethernet-over-usb 
16:36 < jtanx> I think we have to be careful which pins we export/enable
16:37 < jtanx> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
16:37 < jtanx> pages 80-82
16:37 < jtanx> the pins have different meanings based on what mode they're in
16:41 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
17:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:05 < jtanx> ...so I brought the BBB home, even though I should be studying for 2402 :S
18:05 < jtanx> the microphone came in today too
18:19 < jtanx> ok
18:19 < jtanx> so these documents: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
18:19 < jtanx> describes what the pins are  used for by default
19:00 < sam_moore> Ah... they already got the microphone
19:00 < sam_moore> Welp. Guess we're stuck with it.
19:00 < sam_moore> So... we can record <50Hz sounds reliably, maybe
19:00 < sam_moore> How useful
19:01 < sam_moore> Have I been missing out on an email stream where the sensors team actually clears things with us?
19:04 < jtanx> not that I know of
19:04 < jtanx> haha
19:04 < jtanx> in other news
19:04 < jtanx> the sensors team ordered a pressure sensor with no mount
19:04 < jtanx> adrian had a spat because it'd cost something like $200 to make the mount
19:05 < jtanx> for a $10 part
19:05 < jtanx> so he said, order it from online , I don't care if it's from overseas
19:05 < sam_moore> Oh boy
19:06 < sam_moore> If there's an issue with the camera and/or microphone they'll blame us
19:06 < jtanx> yeah
19:06 < jtanx> about that camera
19:06 < sam_moore> Oh dear...
19:06 < sam_moore> Go ahead?
19:06 < jtanx> still couldn't get it to work today
19:06 < sam_moore> God dammit
19:06 < jtanx> although I didn't spend much time on it
19:06 < jtanx> I got pwm to work
19:06 < jtanx> mostly
19:06 < sam_moore> I thought it might be something like adding the user to the "video" group
19:06 < sam_moore> That's good!
19:07 < sam_moore> What was happening?
19:07 < jtanx> yeah, the problem is it doesn't show up at all (the camera)
19:07 < sam_moore> Hmm
19:07 < jtanx> and partly because 3.8 has an issue with usb hotplugging
19:07 < sam_moore> Haha
19:07 < jtanx> about pwm
19:07 < jtanx> it seems that the sysfs method is not so reliable
19:07 < jtanx> you can get it to work
19:07 < jtanx> you have to export those first
19:07 < jtanx> so echo 0 > /sys/class/pwm/export
19:08 < jtanx> then (and only then)
19:08 < jtanx> can you do
19:08 < jtanx> that echo to the slots
19:08 < jtanx> for those pins
19:08 < jtanx> then it seems to be happy
19:08 < jtanx> if you echo am33xx_pwm to the slots when it's already enabled
19:08 < jtanx> that also screws things up
19:08 < sam_moore> Ok
19:09 < sam_moore> Thanks for working that out
19:09 < jtanx> yeah
19:09 < sam_moore> If you want to change from sysfs to the other method that's fine
19:09 < sam_moore> But sysfs was much simpler to code
19:09 < jtanx> should have spent that time studying for mech2402 though :P
19:09 < sam_moore> Because you just sprintf an integer to the path
19:09 < jtanx> yeah
19:09 < jtanx> witht he other way it's all that dynamic path crap
19:09 < sam_moore> Rather than keeping track of "bone_pwm_test_P9_22.15.arbitrary_string" crap
19:09 < sam_moore> Exactly :P
19:09 < jtanx> but
19:10 < jtanx> you can enable pwm and analogue on boot
19:10 < jtanx> if I can find the link
19:10 < sam_moore> Sure, if that's easy
19:10 < sam_moore> I figured if we put them in the /etc/init.d script that'd be fine too
19:10 < sam_moore> Actually... maybe we should put it in the /etc/init.d script
19:11 < jtanx> oh yeah
19:11 < jtanx> and the demo image from that rcn image
19:11 < sam_moore> Because if someone gets a different beaglebone then they'd have to reenable it on boot
19:11 < jtanx> is better than screwing around with recompiling kernels
19:11 < sam_moore> Can you give a link?
19:11 < jtanx> I think it's the first image that you had originally
19:11 < jtanx> http://elinux.org/BeagleBoardDebian
19:12 < jtanx> there's this script in /boot
19:12 < sam_moore> Oh
19:12 < jtanx> that allows you to copy the sd card to flash
19:12 < jtanx> it also enables the usb over ethernet
19:12 < sam_moore> Oh right, the image I downloaded before we used yours
19:12 < sam_moore> Cool
19:12 < jtanx> yeah
19:12 < jtanx> I flashed electronics' one with that
19:12 < sam_moore> Does PWM and stuff work on it?
19:13 < jtanx> probably
19:13 < jtanx> I was using the same image
19:13 < jtanx> on ours
19:13 < jtanx> you run this script and it copies exatly what's on the sd card to the internal flash
19:13 < jtanx> resizes the partition as necessary
19:13 < jtanx> http://digital-drive.com/?p=146
19:13 < jtanx> that page shows how to enable on boot
19:13 < jtanx> it's just a change to uEnv.txt in the boot partition
19:18 < sam_moore> Good work
19:19 < sam_moore> While I remember, for multiple logins and crap... can you just try to login as a local user account?
19:19 < sam_moore> Then we could make a wrapper around adduser and deluser for the "administrator" account
19:19 < jtanx> wow
19:20 < jtanx> I don't know
19:20 < sam_moore> I was just thinking
19:20 < sam_moore> Linux has a user account system already
19:20 < jtanx> yep, but is it a good idea to be making ~300 on a BBB?
19:21 < sam_moore> Well... putting LDAP on the BBB probably won't be less intense
19:21 < sam_moore> I know it's called "Lightweight"
19:21 < sam_moore> But that's in comparison to "DAP"
19:21 < jtanx> well to be perfectly honest, adrian is asking way too much
19:21 < sam_moore> Which was designed in the 1980s by a telephone directory company and used the original OSI networking model
19:21 < jtanx> you simply can't support a 300-odd user base on something like a BBB
19:21 < sam_moore> Yeah
19:22 < sam_moore> But maybe something like 30 users would work?
19:22 < jtanx> yeah
19:22 < jtanx> let's just keep it at that limit
19:22 < sam_moore> Another thing regarding the crazy requirements...
19:22 < sam_moore> If we have multiple Beaglebones running FastCGI
19:23 < sam_moore> We can design our GUI so that it has links to the appropriate Beaglebone for each function
19:23 < sam_moore> I don't think we actually need to do anything in nginx or the Beaglebone software
19:24 < jtanx> hmm
19:24 < sam_moore> At least in terms of displaying sensor data
19:24 < sam_moore> For actuator control, we would need to introduce networking between individual beaglebones
19:24 < jtanx> it actually depends on what he means by 'extensible' and/or distributed
19:24 < jtanx> like
19:24 < jtanx> you could say this BBB is for this experiement
19:25 < jtanx> this other BBB is for this other experiment
19:25 < sam_moore> But quite frankly you'd be mad to trust a distributed system with networking delays to coordinate control over hardware
19:25 < jtanx> well yeah
19:25 < sam_moore> Well at least something like this where we care about safety
19:25 < sam_moore> But if you keep the actual control over hardware independent and on seperate devices
19:25 < jtanx> but I mean
19:26 < jtanx> wait 
19:26 < jtanx> if we interpret it as meaning
19:26 < jtanx> that each BBB runs an instance of the software
19:26 < jtanx> then they would still be separate
19:26 < jtanx> as in each BBB controls one 'experiment'
19:26 < jtanx> you customise each BBB based on the experiment that needs to be done
19:26 < sam_moore> Yes, that would work
19:26 < sam_moore> Yep
19:26 < jtanx> then there's no interaction between BBBS
19:27 < jtanx> the only thing is you have some sort of control at the front
19:27 < jtanx> that determines which BBB you connect to
19:27 < sam_moore> Yes, if there's interaction between BBBs it gets problematic
19:27 < jtanx> yeah
19:27 < sam_moore> Yes, you have one BBB which gives the user the "main menu" part of the GUI
19:27 < jtanx> I reckon that's a stupid requirement to ask
19:27 < jtanx> yeah
19:27 < sam_moore> Then the others just have customised GUIs or whatever
19:28 < jtanx> once you have to get them to talk to each other, you're then having to try and invent a whole new protocol
19:28 < jtanx> for that
19:28 < sam_moore> Yeah, and it depends on exactly what the hardware is
19:29 < sam_moore> You might be able to hack it onto the web protocol (eg: BeagleBone #1 sends http://beaglebone2/api/actuators?id=X?set=Y)
19:29 < sam_moore> But... let's not think about that
19:30 < sam_moore> It's clearly beyond the scope of this project
19:31 < sam_moore> So, after all that, I reckon if we use snoopy for ADC/GPIO/PWM and spike for the dilatometer then that would be cool (probably not actually necessary though)
19:31 < jtanx> yeah
19:32 < sam_moore> The dilatomter... it's going to cause headaches if Kieren really wants to "return" an array of points
19:33 < sam_moore> If the goal is to provide the user with a demonstration of what the dilatometer is doing, then you can just edit an image
19:33 < sam_moore> If the goal is to provide more data... I don't see the point really
19:34 < sam_moore> It's going to be the same sort of distribution every time
19:34 < sam_moore> Realistically all anyone would do is average it
19:34 < sam_moore> Maybe take a standard deviation
19:36 < jtanx> I really don't know why a dilatometer's even needed
19:36 < sam_moore> Educational reasons? :P
19:37 < jtanx> haha sure
19:37 < sam_moore> Anyway, hopefully Callum will deal with the dilatometer stuff
19:37 < sam_moore> The interferometer code is a good starting point
19:39 < jtanx> Yeah
19:39 < jtanx> hopefully
19:42 < sam_moore> We should arrange some meetings next week
19:42 < sam_moore> Also I'd like to see more of the other group members committing to git and talking in this channel
19:45 < sam_moore> People are missing a lot of design decisions here :S
19:45 < jtanx> Yeah
19:51 < jtanx> Ok
19:51 < jtanx> so I made a LUT from pin number on the board to GPIO pin number
19:52 < jtanx> so if you wanted to use P8_13
19:52 < jtanx> you can use the lut to figure out what gpio number that corresponds to
19:53 < jtanx> we should probably restrict which pins can be used
19:53 < jtanx> because quite a few are reserved
19:53 < sam_moore> Sure
19:53 < sam_moore> Remove the #defines in bbb_pin_defines.h ?
19:54 < sam_moore> Don't export those pins in pin_test.c
19:54 < sam_moore> It is only really for testing anyway
19:54 < jtanx> yeah
19:55 < sam_moore> Although... I predict if we leave it in the software, *someone* at some point will try and control hardware directly through it :P
19:55 < sam_moore> For all the educational stuff it's nice though
19:56 < sam_moore> Oh, we could have an image of the pinout diagram
19:56 < sam_moore> And when someone clicks on a part of the image they get to control that pin
19:57 < sam_moore> Anyway... I really should study for MECH2402 or I will fail it
19:57 < sam_moore> So bye
19:57 < jtanx> yeah
19:57 < jtanx> bye
20:50 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
21:50 -!- MctxBot [[email protected]] has quit [Ping timeout]
--- Day changed Thu Sep 26 2013
07:45 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:36 -!- jtanx [[email protected]] has quit [Ping timeout]
09:36 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:47 -!- jtanx [[email protected]] has quit [Ping timeout]
13:08 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:26 -!- jtanx [[email protected]] has quit [Ping timeout]
17:04 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
17:52 < jtanx> http://www.ti.com/lit/ug/spruh73i/spruh73i.pdf p1986 (chapter 15) on pwm
17:55 < jtanx> page 1996 on ePWM
17:56 < jtanx> ahhhhh
17:56 < jtanx> for ehrpwm0a/0b
17:56 < jtanx> the frequency is linked
18:08 < jtanx> ehrpwm is enhanced resolution pwm
18:08 < jtanx> Implemented using the A signal path of PWM, that is, on the EPWMxA output. EPWMxB output has
18:08 < jtanx> conventional PWM capabilities
18:08 < jtanx> (p2053)
19:06 < jtanx> if you want to make the pwm stuff not suck
19:06 < jtanx> there's this file called pwm_test.c
19:06 < jtanx> that's the driver
19:59 < jtanx> for future ref: http://armsdr.blogspot.com.au/2013/04/archlinux-on-beaglebone-and-linux-38.html
20:08 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
20:21 -!- jtanx [[email protected]] has quit [Ping timeout]
21:19 < jtanx_> urgh wow
21:19 < jtanx_> ok, so I think pwm1/3/5 shouldn't be used to avoid period conflicts
21:19 < jtanx_> (pwm0/1 is for channel A/B of one pwm device, 3/4 another, 5/6 another)
21:20 < jtanx_> btw the correspondence between pwmX and pin number is:
21:21 < jtanx_> P9_22, P9_21, P9_42. P9_14, P9_16, P8_19, P8_13, P9_28
21:23 < jtanx_> pwm 2/7 correspond to eCAP devices
21:24 < jtanx_> which I think are to capture PWM input
21:24 < jtanx_> but they can also be used to generate PWM output, afaik
23:08 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
23:10 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
--- Day changed Fri Sep 27 2013
12:38 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:29 < jtanx> so, apparently if we don't order stuff that we need before the mid semester break (ie today), adrian just won't order it
13:29 < jtanx> in other news, I think I've mostly sorted out pwm
13:43 < jtanx> trying to standardise the pin code
15:05 -!- jtanx [[email protected]] has quit [Ping timeout]
15:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
16:09 -!- MctxBot [[email protected]] has quit [Ping timeout]
19:48 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
20:03 -!- jtanx [[email protected]] has quit [Ping timeout]
20:10 < jtanx_> lol
20:10 < jtanx_> we have a file authored '14 years ago'
20:10 < jtanx_> in git
20:10 < jtanx_> talk about commitment
20:20 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
21:47 < jtanx_> so on non-BBB platforms, I disabled the pin code
21:47 < jtanx_> required some pretty dubious hacks to stop gcc from complaining
21:48 < jtanx_> 1st attempt: define the functions to nothing
21:48 < jtanx_> gcc complains about statements that do nothing
21:48 < jtanx_> various combinations later on statements that do nothing, I move to making function stubs
21:49 < jtanx_> shaft all the parameters to the stubs
21:49 < jtanx_> to stop complaints about unused variables
21:49 < jtanx_> (eg if you did int freq=1000; PWM_Set(...,freq) where the define for PWM_Set doesn't use freq
21:53 -!- jtanx_ [[email protected]] has quit [">.>"]
22:14 -!- MctxBot [[email protected]] has quit [Ping timeout]
22:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
22:20 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
23:12 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sat Sep 28 2013
10:03 -!- MctxBot [[email protected]] has quit [Ping timeout]
11:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
--- Log closed Sat Sep 28 12:20:39 2013
--- Log opened Sat Sep 28 12:26:58 2013
12:26 -!- sam_moor1 [[email protected]] has joined #mctxuwa_softdev
12:26 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
12:27 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
12:31 -!- sam_moore [[email protected]] has quit [Ping timeout]
13:18 -!- jtanx [[email protected]] has quit [Ping timeout]
18:26 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:53 -!- jtanx [[email protected]] has quit [Ping timeout]
20:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:36 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Log closed Sun Sep 29 08:28:33 2013
--- Log opened Sun Sep 29 08:31:40 2013
08:31 -!- matches [[email protected]] has joined #mctxuwa_softdev
08:31 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
08:31 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
08:31 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
08:31 -!- You're now known as sam_moore
13:18 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
15:27 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
15:27 < Rowan> hey jeremy, did you upload the updated gui onto a github? i cant find it anywhere ??
15:32 < sam_moore> Hi Rowan, I think it's in a few subdirectories
15:33 < sam_moore> Ah, it's under "testing/MCTXWeb"
15:33 < sam_moore> https://github.com/szmoore/MCTX3420/tree/master/testing/MCTXWeb/public_html
15:37 < Rowan> thats the most uptodate version?
15:39 < jtanx> um
15:39 < jtanx> maybe
15:39 < jtanx> I'll update with what I've got now
15:42 < jtanx> ok
15:42 < jtanx> updated
15:42 < jtanx> pintest stuff still not complete
15:42 < Rowan> are you guys busy?
15:42 < Rowan> (will you be on here long?
15:42 < jtanx> right now I'm working on that pintest page
15:42 < jtanx> I'm here
15:43 < Rowan> in g19?
15:43 < jtanx> no
15:43 < jtanx> I'm at home
15:43 < Rowan> okay
15:43 < sam_moore> jtanx: As in, the pin control code isn't working? I didn't think I screwed it up that badly?
15:43 < jtanx> nah 
15:43 < jtanx> the pin control web page
15:43 < sam_moore> Oh, nice
15:43 < jtanx> just thought it'd be easier to have a webpage to control stff
15:43 < sam_moore> Yes
15:43 < jtanx> especially for electronics
15:43 < sam_moore> Yes, definitely
15:44 < Rowan> are we going to make the gui UWA based or make it our own ?
15:44 < Rowan> adrian made it sound like he wanted it UWA based with the logo and stuff
15:44 < jtanx> we probably have to add uwa logo
15:44 < sam_moore> We should probably put the UWA logo on it
15:44 < sam_moore> Yes
15:45 < Rowan> so make it similar to the main UWA page or make it similar to LMS?
15:46 < Rowan> does anyone know if IT are in this week?
15:46 < jtanx> we need to make it Colourful
15:47 < jtanx> I don't think it needs to be exactly like UWA page or LMS
15:47 < jtanx> just something similar would be good
15:47 < sam_moore> I think LMS is probably a bad example, lots of people hate it
15:48 < jtanx> haha
15:48 < jtanx> I think LMS is fine, although there seems to be alot of problems with it on the backend
15:48 < Rowan> yeah but adrian loves it
15:48 < Rowan> keeting uses it for all 5 units hes teaching
15:49 < Rowan> has anyone heard from james about the gui, i think he uploaded something to dropbox
15:49 < jtanx> really
15:49 < jtanx> I haven't checked db
15:49 < jtanx> why's he not using git
15:50 < Rowan> i dont know. has he uploaded anything to it/
15:50 < Rowan> he might be.
15:50 < Rowan> sometime last week he said he made up a gui todo list type thing but i dont know where he put it
15:50 < sam_moore> It doesn't look like there is anything in dropbox
15:50 < jtanx> right
15:51 < Rowan> im trying to get in contact with him but i might just move on. so we want something somewhat related to lms?
15:51 < Rowan> or no?
15:52 < sam_moore> I think so, although it primarily needs to be able to control experiments
15:52 < sam_moore> For the educational stuff, you could use a wiki style
15:53 < sam_moore> https://github.com/szmoore/MCTX3420/wiki
15:54 < Rowan> wiki isnt graphical enough
15:54 < sam_moore> Yeah, probably
15:54 < Rowan> its hard to say what adrian wants....
15:54 < sam_moore> It looks like James has committed something to his own fork of the repository
15:55 < jtanx> ok
15:55 < sam_moore> https://github.com/firefields/MCTX3420/commit/e6a8120fdf1cef6d73421bd2b1edb1c45a6f3960
15:55 < sam_moore> I can pull that into the main fork
15:55 < sam_moore> Hopefully
15:55 < jtanx> I think that may actually be
15:56 < jtanx> sorry
15:56 < jtanx> my computer decided to freeze at that instant
15:57 < jtanx> but yeah that's the stuff
15:57 < jtanx> he worked on 
15:57 < sam_moore> Oh wow... there are a *lot* of files
15:57 < jtanx> before mine
15:57 < jtanx> it's all the jquery ui stuff
15:57 < sam_moore> jquery-ui
15:57 < sam_moore> Yes
15:57 < jtanx> wich I  told him to get rid off
15:57 < sam_moore> Dammit I just merged it :S
15:57 < jtanx> but yeah, he hasn't committed anything since
15:58 < jtanx> (that commit was done with me at the last meeting)
15:58 < Rowan> so are we deciding on jeremys version it seems alot more complete
15:59 < sam_moore> Yes, stick with Jeremy's and build on it
15:59 < Rowan> sweet :)
16:46 < Rowan> what was the password and username ?
16:48 < jtanx> there's none
16:48 < jtanx> if you haven't set up the htpasswd thing
16:48 < jtanx> (ie it doesn't work)
16:48 < jtanx> still not sure how to implement it either
16:48 < jtanx> now that adrian wants it scalable to '300 students'
16:53 < jtanx> I need another network switch...
16:53 < Rowan> okay.
16:53 < Rowan> i might make up a cover page, which links to the one we have after you log in
16:54 < Rowan> like this but simpler: http://www.futureeffect.com.au/
16:54 < Rowan> with a scrolling picture thing and stuff
16:54 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
16:55 < MctxBot> I live again...
16:55 < Rowan> whos mctxbot again?
16:56 < jtanx> :P
16:56 < jtanx> It does nothing
16:56 < Rowan> its a cover page
16:56 < Rowan> its what adrian said
16:56 < jtanx> It connects whenever mctx.us.to is running
16:57 < Rowan> what what
16:57 < Rowan> ?
16:58 -!- MctxBot changed the topic of #mctxuwa_softdev to: MCTX3420 - Software and co.
16:59 < jtanx> mctxbot is no one, it's the server I operate
17:02 < Rowan> hahahahah
17:02 < Rowan> oh.
17:03 < Rowan> ive put the uwa logo onto the gui
17:09 < sam_moore> I'm looking at the login stuff
17:10 < sam_moore> So... we probably don't want to use shell accounts, since once you have shell access you can do all sorts of things that are completely unrelated to this educational stuff
17:10 < Rowan> could someone check ive forked it right
17:10 < sam_moore> I think storing our own file in the same format as /etc/shadow is probably ok
17:11 < Rowan> the gui.html & style.css
17:12 < sam_moore> It looks like you've made a new branch for each of the files?
17:12 < Rowan> i think so
17:12 < Rowan> do you need to update the main file and i request it to you
17:13 < Rowan> just so everything is uptodate and and organised
17:13 < sam_moore> You submitted a pull request, that's fine
17:13 < sam_moore> Yep
17:13 < Rowan> both html and css files
17:13 < sam_moore> You should probably keep edits in the "master" branch, or at least don't make a seperate branch for each file
17:14 < sam_moore> (That way you only have to do one pull request for all of them, not one per file)
17:14 < Rowan> how do i do that :|
17:14 < sam_moore> Are you using a GUI or the command line?
17:15 < Rowan> gui
17:15 < jtanx> I think you were working on an old version
17:15 < jtanx> before I pushed the new one
17:15 < sam_moore> Hmm
17:15 < jtanx> so some stuff got deleted
17:15 < Rowan> S***
17:15 < jtanx> https://github.com/szmoore/MCTX3420/commit/f43006da69d629d0c5421506c8a56d517b94924e
17:15 < jtanx> it's ok
17:16 < sam_moore> jtanx: It should have complained if there was a conflict?
17:16 < jtanx> I dunno
17:16 < Rowan> i only added 1 line to the css file anyways
17:16 < jtanx> yeah
17:16 < jtanx> so the form.controls, div.centre .bold etc
17:16 < jtanx> stuff was added later
17:18 < Rowan> when im home ill try put a cover page with pictures and the login page on it and link the login page to the gui we have atm.
17:18 < Rowan> any constructive critism ?
17:19 < Rowan> also ill try be on irc for the rest of the sem to keep up todate with you guys :)
17:21 < sam_moore> The future effect looks cool
17:21 < sam_moore> I guess we need to pick some relevant images though
17:21 < Rowan> yeah ill talk to some other teams and see if they have any cool pics, like the can were testing, the cad model ect
17:22 < Rowan> ttyl
17:22 < jtanx> has this been pushed to your (sam's) repo?
17:22 < sam_moore> I accepted a pull request a while ago
17:22 < sam_moore> But I noticed Rowan has two branches in his fork; there's one file changed in each branch
17:23 < jtanx> oh ok
17:23 < jtanx> because I don't see any change except for some css stuff in your repo
17:24 < sam_moore> Rowan: I'll try and get in earlier tomorrow to help with the "branching" stuff in git
17:25 < sam_moore> It looks like your git GUI might have some wierd settings
17:28 < MctxBot> damn ircnet
17:29 < MctxBot> 'Too many user connections (local))'
17:29 < MctxBot> so i'll steal mctxbot for now
17:38 -!- Rowan [[email protected]] has quit [Ping timeout]
17:42 -!- jtanx [[email protected]] has quit [Ping timeout]
17:42 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
17:42 -!- jtanx_ is now known as jtanx
17:43 < jtanx> finally
17:52 < sam_moore> So, we can implement our own login system fairly easily, I'm not sure if we want to or not, although I'm leaning towards just doing it
17:53 < sam_moore> It wouldn'
17:54 < sam_moore> t necessarily be the best solution in terms of flexibility
17:54 < sam_moore> But it's probably a hell of a lot more "lightweight" than LDAP
17:55 < sam_moore> Using LDAP you'd have to dedicate processes just to being a login server
17:56 < sam_moore> So... we provide some wrappers around a text file of usernames and password salts, and allow "admin" to use wrappers that change the files
17:57 < sam_moore> ... I suppose we can have a "forgot password" functionality
17:57 < sam_moore> Though it is certainly a pain
17:59 < sam_moore> I feel like we should have "forgot password" but make it ridiculously painful to use, for revenge
17:59 < sam_moore> ...errr I mean security reasons
17:59 < sam_moore> Did I say "revenge?"
18:00 < sam_moore> "Forgot password" should activate one of the ADC channels and record the average over 10s
18:01 < sam_moore> And you have to enter what it was
18:01 < sam_moore> No wait, any student could do that
18:01 < sam_moore> Hmmm
18:03 < sam_moore> "Your password has been sent via Australia Post to your registered address"
18:04 < jtanx> hahaha
18:04 < jtanx> evil
18:04 < jtanx> I was kinda hoping there was some ready made
18:04 < jtanx> gateway software
18:05 < jtanx> like you know the SSO services that uwa uses
18:05 < sam_moore> Yeah, that's an LDAP gateway
18:05 < jtanx> yeah but like a simplified version
18:05 < sam_moore> Haha
18:05 < jtanx> that just uses an sql database or something
18:05 < jtanx> slap it on and we're done
18:06 < sam_moore> Yeah I guess we should look for that
18:06 < sam_moore> Do we allow users to change their password?
18:06 < sam_moore> Ooh
18:06 < sam_moore> Our system is on the UWA network...
18:06 < sam_moore> Could we just wrap to UWA's LDAP servers?
18:06 < sam_moore> And... um...
18:07 < jtanx> do they trust us that much?
18:07 < sam_moore> They can't really stop us
18:07 < sam_moore> You can bind to the LDAP servers already
18:07 < sam_moore> It's not like they can...
18:07 < jtanx> really?
18:07 < sam_moore> Put in a login or something
18:07 < sam_moore> That you have to go through first
18:07 < jtanx> well then
18:07 < sam_moore> :P
18:08 < sam_moore> Hang on, there's some horribly verbose way to test it in a shell
18:08 < jtanx> my god why is it so hard to vertically align content in css
18:14 < sam_moore> ldapsearch -x -D cn=20503628,ou=Students,ou=Users,ou=UWA,dc=uwads,dc=uwa,dc=edu,dc=au -h ldap.pheme.uwa.edu.au -W -v -b cn=20503628,ou=Students,ou=Users,ou=UWA,dc=uwads,dc=uwa,dc=edu,dc=au
18:14 < sam_moore> Replace 20503628 with your own student number
18:14 < sam_moore> So
18:14 < sam_moore> Basically we can wrap to ldapsearch using their username and password
18:14 < jtanx> I wonder what adrian has to say about that
18:15 < sam_moore> Well, obviously he doesn't want just *any* student being able to access it :S
18:15 < sam_moore> But...
18:15 < sam_moore> We could have a plain text file of students
18:15 < sam_moore> That he can change
18:15 < sam_moore> Also...
18:16 < sam_moore> UWA IT might have a problem
18:16 < sam_moore> It would be ridiculously easy to put a back door in to steal student's passwords :S
18:16 < jtanx> yeah
18:16 < sam_moore> But... I guess people would just use their pheme password anyway
18:17 < sam_moore> I mean, I would
18:18 < sam_moore> http://xkcd.com/792/
18:18 < sam_moore> I reckon we implement the system to bind to UWA's ldap servers, obviously don't do anything unethical
18:19 < jtanx> :P
18:19 < jtanx> what about jellyfish, calmaeth
18:19 < sam_moore> And warn Adrian that if he lets random students work on this they can potentially do unethical things
18:19 < sam_moore> What do they use for login?
18:20 < jtanx> they roll their own I think
18:20 < jtanx> but obviously there's some way to import users
18:20 < sam_moore> Hmm
18:20 < sam_moore> I like the idea of using UWA's pheme server though
18:21 < sam_moore> Just add a list of allowed student numbers in front of it
18:21 < sam_moore> Actually, staff as well
18:21 < jtanx> yeah true
18:21 < sam_moore> No wait
18:22 < sam_moore> That could end in the staff member accidentally deleting themselves
18:22 < sam_moore> Um...
18:22 < sam_moore> Just hard code in Adrian's staff number as always allowed :P
18:22 < sam_moore> Ergh, so many annoying things that have nothing to do with blowing up a pressure vessel -_-0
18:23 < sam_moore> Ok, I'll try do some more on the login tomorrow
18:23 < jtanx> ok cool
18:23 < jtanx> I'll try to come in early tomorrow too
18:23 < jtanx> though I really should be working on my other projects too...
18:24 < sam_moore> Well, we're doing alright on the list of things Todo
18:24 < sam_moore> Not sure how well we're doing by Adrian's standards
18:24 < sam_moore> Oh, all that GUI stuff isn't getting done very afst
18:24 < sam_moore> *fast
18:24 < jtanx> yeah
18:25 < sam_moore> Also haven't heard anything about image processing from Callum
18:25 < jtanx> I wonder if james has done anything at all
18:25 < sam_moore> Oh well... I'll do logins this week
18:25 < jtanx> Adrian doesn't seem to like how most of the groups are going
18:26 < sam_moore> Well, not much has happened with other groups I suppose
18:26 < sam_moore> We've written a lot of software, but it's all low level
18:26 < jtanx> I also think he underappreciates the effort required for the software though
18:27 < sam_moore> I think so
18:27 < sam_moore> Though we really should have more GUI stuff done
18:28 < jtanx> yeah
18:28 < jtanx> we really do need to make progress on that
18:52 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
19:12 < jtanx> firebug slows down my computer so much
19:22 < jtanx> ok I just updated the gui stuff a bit
19:22 < jtanx> ...now back to testing if this pin test html page works
19:32 < jtanx> well hey
19:32 < jtanx> it works
19:33 < jtanx> Should probably do reference counting on the export/unexport stuff though
19:36 < jtanx> actually maybe not
19:40 -!- MctxBot [[email protected]] has quit [Ping timeout]
19:46 < sam_moore> I think DAP (which is what LDAP was based on) wasn't actually meant to be a login system when they designed it :P
19:46 < sam_moore> But it's used for that more than anything else
19:46 < sam_moore> Essentially it was supposed to be like an electronic telephone directory
19:47 < sam_moore> Then they realised that it was a bad idea for any random person to be able to edit stuff, so authentication got added to it
19:47 < sam_moore> And now it's pretty much just used for authentication
19:48 < sam_moore> There seems to be a sane C library for it, so if we just implement a client and rely on the good IT staff at UWA to keep pheme working...
19:49 < sam_moore> (Does UWA even still hire IT staff?)
19:49 < sam_moore> (Someone told me they "integrated" the librarians into IT)
19:50 < sam_moore> We'll need to put our login page under HTTPS at some point
19:52 < jtanx> I was just thinking
19:53 < jtanx> put the whole damn thing under ssl
19:53 < jtanx> and be done with it
19:54 < jtanx> hmm interesting
19:54 < jtanx> if you query the adc on different channels 
19:55 < jtanx> and you query too fast
19:55 < jtanx> it'll spit back that it's temporarily unavailable
19:55 < jtanx> probably can't change the mux that fast?
19:56 < sam_moore> Maybe
19:56 < sam_moore> It's kind of ironic that the ADC hardware has a multiplexer to give the extra channels
19:57 < sam_moore> And then we are sticking another multiplexer on that
19:57 < jtanx> :P
19:57 < sam_moore> But I suppose if it means we don't need 4 of the same amplifier that's nice
20:03 < jtanx> ok well the pintest page works good enough
20:04 < jtanx> some race conditions
20:04 < jtanx> but eh
20:04 < jtanx> who cares
20:04 < jtanx> ohhh I know what's slowing down the bb
20:04 < jtanx> bbb*
20:04 < jtanx> the crazy high sampling rate
20:04 < jtanx> the test files also constantly eat up all the space on my 1gb sd card
20:06 < jtanx> ..or maybe not
20:55 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
20:57 < sam_moore> It turns out UWA uses LDAP to keep track of what units you're enrolled in
20:57 < sam_moore> That's interesting...
20:58 < sam_moore> Potentially we could restrict access to people enrolled in MXTC3420
20:58 < sam_moore> That would mess with the new courses :P
20:59 < sam_moore> And it appears you can connect to ldap.pheme.uwa.edu.au from UWA's network
20:59 < sam_moore> But... it also appears to use the unsecured LDAP port?
20:59 < sam_moore> Surely not
20:59 -!- MctxBot [[email protected]] has quit [EOF From client]
20:59 < jtanx> what
21:00 < sam_moore> Or maybe (hopefully) they are doing TLS
21:00 < sam_moore> http://wiki.wireshark.org/LDAP
21:00 < jtanx> one would hope that there's some sort of encryption going on
21:00 < sam_moore> Well, there's HTTPS on the SSO page
21:01 < sam_moore> But if there isn't actually encryption on the ldap connection
21:01 < sam_moore> You could just plug into a switch and do some packet sniffing and get everyone's passwords :O
21:01 < jtanx> haha wow
21:02 < sam_moore> I think they might be using TLS, because my test program doesn't work
21:02 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
21:07 < sam_moore> ... Or I'm just deleting one more character than I should be in the password -_
21:11 < sam_moore> Test program works now
21:11 < sam_moore> Either the ldap library kindly handles TLS for you automagically, or they aren't using it
21:12 < jtanx> :S
21:12 < jtanx> if you used wireshark wouldn't it show whether or not it's encrypted
21:16 < sam_moore> I've just run it through wireshark
21:16 < sam_moore> It's not encrypted
21:17 < sam_moore> My password for pheme appears plain as day
21:17 < jtanx> well that sounds dodgy as hell
21:18 < sam_moore> Well, you do have to have root access to a machine that can pick up the traffic
21:18 < sam_moore> But yes, that sounds dodgy
21:18 < sam_moore> Hang, on a minute
21:18 < sam_moore> What about Unifi
21:19 < sam_moore> Well...
21:19 < sam_moore> I think this should be filed under "Not our problem"
21:20 < jtanx> ._.
21:21 < sam_moore> Surely there's some kind of handshake encryption on Unifi though
21:22 < sam_moore> Anyway, I have a test function that returns true if you can login to pheme, so if we integrate that with our code and maybe modify it to look at enrolled units, that's a good start
21:23 < sam_moore> Actually I also need to make it work without using deprecated functions
21:25 < sam_moore> At least the library maintainers still keep the deprecated functions, but it's annoying when something that works perfectly fine and has tonnes of documentation is replaced by something that has almost no documentation
21:25 < sam_moore> Almost like the new UWA courses...
21:25 < jtanx> hahaha
21:25 < jtanx> what's worse is where the new function is a PITA to use by design
21:26 < sam_moore> Yes
21:27 < sam_moore> The "deprecated" version has "LDAP * ld = ldap_init(host, port); ldap_set_options(ld, LDAP_OPT_PROTOCOL_VERSION, &version); and ldap_bind_s(ld, dn, password, authentication_method);"
21:27 < sam_moore> That makes perfect sense to me
21:27 < sam_moore> No doubt the new and improved version takes 100x as much code
21:28 -!- Rowan [[email protected]] has quit [EOF From client]
21:28 < sam_moore> Although admittedly I was confused as to why the ldap_set_options required a pointer to the integer instead of just passing the integer
21:28 < sam_moore> It probably modifies it in some cases though
21:31 < jtanx> which package installs ldap
21:31 < sam_moore> libldap2-dev
21:31 < jtanx> thanks
21:31 < sam_moore> For development libraries
21:32 < sam_moore> ldap-utils for tools like ldapsearch
21:32 < sam_moore> At the moment I can only find documentation for libldap-dev (the deprecated stuff)
21:32 < sam_moore> To get it to work, you just put a #define LDAP_DEPRECATED 1 before the #include <ldap.h>
21:33 < jtanx> http://man.devl.cz/deb/l/libldap2-dev ?
21:33 < sam_moore> Oh, well there you go
21:33 < sam_moore> Thanks
21:34 < sam_moore> No wait, it has all those functions the compiler was complaining about
21:34 < sam_moore> ?
21:34 < jtanx> ok then
21:34 < sam_moore> Except there's this fsfuncLDAP instead of LDAP
21:36 < sam_moore> ...
21:36 < jtanx> oh that documentaiton is so terrible: http://www.openldap.org/doc/
21:37 < jtanx> the html version is at least
21:37 < sam_moore> Yeah
21:38 < sam_moore> Um... given that the only documentation for libldap2 documents the "deprecated" functions, I'm going to continue using those functions
21:39 < sam_moore> Installing libldap2-dev installed all those man pages
21:39 < jtanx> yep
21:39 < jtanx> >.>
21:41 < jtanx> ldap_init(3) was obsoleted by ldap_initialize(3)
21:41 < jtanx> http://www.openldap.org/lists/openldap-bugs/200509/msg00151.html
21:42 < sam_moore> Seriously
21:43 < sam_moore> Please tell me they changed more than just the name...
21:44 < sam_moore> Oh great, they did, now I need to work out how to use it
21:44 < jtanx>        int ldap_initialize(ldp, uri)
21:44 < jtanx>        LDAP **ldp;
21:44 < jtanx>        char *uri;
21:44 < jtanx> wow, that's old school way of specifying the type of the input arguments
21:45 < jtanx> I've only seen that style once elsewhere
21:45 < jtanx> In code from the ~1990s
21:45 < sam_moore> LDAP was invented in the 80s
21:45 < sam_moore> So that would make sense
21:45 < jtanx> you'd think they'd update the manpages by now though
21:46 < sam_moore> They don't even note in the man page that ldap_init is depreated
21:46 < jtanx> yeah
21:46 < jtanx> the joys of poor documentation
21:46 < sam_moore> At least the function names make sense
21:46 < sam_moore> initialize
21:47 < sam_moore> Obvious what that does
21:47 < sam_moore> ... I think the "uri" includes the port
21:47 < sam_moore> Like "ldap://server" or "ldaps://server"
21:47 < jtanx> yep
21:48 < jtanx> the whole ldap_init vs ldap_initialize reminds me of fopen vs fopen_s on windows
21:48 < sam_moore> That's going to screw with anyone that puts their ldap server on a non-standard port for security-by-obscurity reasons
21:48 < jtanx> couldn't you do
21:48 < jtanx> ldap://server:port
21:48 < sam_moore> Oh
21:48 < sam_moore> Probably
21:56 < sam_moore> Sigh... they deprecated ldap_bind and made ldap_simple_bind and then at some point that got deprecated too
21:57 < sam_moore> Now it's ldap_sasl_bind_s
21:57 < jtanx> what's with that naming convention
21:57 < sam_moore> sasl stands for something
21:57 < jtanx> _s for secure
21:57 < jtanx> yey
21:57 < sam_moore> The LDAP expert at UCC was basically like "It's terrible, no one ever uses it, but the LDAP standards wanted to put it in, so it's there"
21:57 < sam_moore> And that's all I know
21:58 < jtanx> gee ok
21:59 < sam_moore> But as opposed to ldap_simple_bind(ld, dn, password)
21:59 < sam_moore> You have something like 10 arguments?
21:59 < sam_moore> Please let half of them be NULL...
22:12 < jtanx> that's all for today
22:12 < jtanx> bye
22:12 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
23:07 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
23:19 < sam_moore> Hi Rowan
23:19 < Rowan> hello
23:19 < sam_moore> I'm working on getting logins with UWA's pheme system
23:19 < sam_moore> So it will be kind of like LMS
23:24 < Rowan> are we trying to keep the gui to only a few pages or can we use several.
23:25 < Rowan> like a cover page(a link to just the stream, a link to dump data and a login). then the login page goes to the experiment page
23:26 < sam_moore> I think several pages
23:26 < sam_moore> Probably even one page per sensor?
23:26 < Rowan> sweet, i shall enjoy this gui :)
23:41 < sam_moore> See you tomorrow
23:47 < Rowan> yep
--- Day changed Mon Sep 30 2013
03:31 -!- Rowan [[email protected]] has quit [Ping timeout]
10:57 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:10 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
11:17 < sam_moore> Hi Rowan, do you have anything we should put in the report?
11:34 -!- Rowan [[email protected]] has quit [Ping timeout]
11:58 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
11:59 < Rowan> ill have the outline of all the pages i wanted on git this afternoon
12:05 < sam_moore> Ok
12:42 -!- Rowan [[email protected]] has quit [Connection reset by peer]
12:44 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
13:33 < Rowan> so far i have a cover page which links to a login page which links to the index page. but theres no styles for them and no security on the login
14:09 < Rowan> im not sure the files ive added went into sams git. im pretty sure they all forked over to mine. :S
14:58 -!- Rowan [[email protected]] has quit [Ping timeout]
15:20 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
15:57 -!- Rowan [[email protected]] has quit [Ping timeout]
16:18 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
16:18 -!- jtanx [[email protected]] has quit [Ping timeout]
16:31 -!- Rowan [[email protected]] has quit [EOF From client]
18:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
18:55 -!- MctxBot [[email protected]] has quit [Ping timeout]
21:18 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
21:44 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
22:06 -!- Rowan [[email protected]] has quit [EOF From client]
--- Day changed Tue Oct 01 2013
08:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:03 -!- jtanx [[email protected]] has quit ["brb"]
11:04 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:40 < sam_moore> Another option for the login system (a really terrible option that I don't condone on any real world system, but it might just get us marks)
13:40 < sam_moore> Is to provide some cgi scripts that wrap around "useradd" "userdel" and "usermod"
13:40 < sam_moore> And have our "Login" function check /etc/shadow
13:41 < sam_moore> I emailed UWA IT help desk about Pheme anyway
13:41 < sam_moore> I wonder what they'll make of it...
13:51 < jtanx> hehe
13:52 < sam_moore> The more I think about it, the more I think LDAP is the way you'd do this properly though
13:52 < sam_moore> It basically is a text file
13:53 < jtanx> yeah
13:53 < sam_moore> If you started with a text file, you'd quickly find yourself reinventing the wheel and probably converging with what LDAP already does
13:53 < jtanx> I guess the real problem is that rolling our own solution is not really feasible in the time left, especially if you want to ensure it's at least ok in terms of security
13:57 < sam_moore> Yes
14:08 < sam_moore> For reference: http://www.debuntu.org/how-to-set-up-a-ldap-server-and-its-clients/
14:09 < sam_moore> And http://mindref.blogspot.com.au/2010/12/openldap-create-user.html
14:09 < sam_moore> (How to set up our own LDAP server)
14:11 < jtanx> slapd
14:12 < jtanx> what a weird choice of a name
14:12 < sam_moore> Haha
14:15 < jtanx> oh 
14:15 < jtanx> if you set up an ldap server
14:15 < jtanx> http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page
14:15 < jtanx> get them to manage the ldap database themselves
14:15 < jtanx> :P
14:15 < jtanx> to add or remove users
14:22 < sam_moore> Yeah, that's kind of how ldap was designed
14:22 < sam_moore> Technically I can probably modify my UWA "pheme" password from a command line using ldappasswd
14:22 < sam_moore> Unless they use kerberos
14:23 < sam_moore> (We don't want to start going into kerberos...)
14:54 < sam_moore> Welp, I've put an LDAP server on my laptop for testing purposes
14:54 < sam_moore> With an account "snoopy"
14:55 < sam_moore> Seems to work... now to test it with our software
14:55 < sam_moore> Hey, maybe we could just put an LDAP server on the BeagleBone and get a GUI LDAP editor
14:56 < sam_moore> Oh right, you suggested that at 14:15
14:56 < sam_moore> I like it though
14:58 < jtanx> yah not too bad
14:58 < jtanx> say we had an ldap server on the bbb
14:59 < jtanx> we could even write the password manager in a different language
14:59 < jtanx> if we wanted to make one
14:59 < sam_moore> Yeah, exactly
14:59 < jtanx> because it only has to interact with the ldap database
14:59 < sam_moore> We shouldn't do that in the FastCGI program
14:59 < jtanx> yup
15:00 < sam_moore> I sent an email about it to everyone, suggesting PHP or python CGI to wrap around LDAP
15:01 < sam_moore> I wonder when this system is going to start being put together though
15:02 < sam_moore> We'll end up with a server and no hardware to control
15:02 < jtanx> Looks like it
15:02 < sam_moore> Those images Justin sent us look nice
15:02 < jtanx> Yeah they look quite good
15:07 < sam_moore> With the FastCGI program
15:07 < sam_moore> Do you think it's better to pass options through the command line
15:07 < sam_moore> Or have a bunch of #defines that need to get configured?
15:08 < sam_moore> eg: To specify the LDAP server
15:08 < sam_moore> (At the moment it's just a #define)
15:08 < jtanx> hmm
15:08 < jtanx> It's probably better to pass as a command line
15:09 < sam_moore> Ok
15:09 < jtanx> unless we're absolutely sure that the ldap address is fixed
15:10 < sam_moore> What we can do is write a bash script that sets a bunch of variables
15:10 < sam_moore> Then run.sh sources that and passes them all as arguments
15:10 < jtanx> sounds good
15:35 < sam_moore> What about things like the path to the GPIO and ADC? I figure they should stay as #defines
15:35 < sam_moore> Since they probably won't be changing
15:36 < sam_moore> At least not until the next BeagleBone kernel comes out
15:36 < jtanx> hehe
15:36 < jtanx> yeah that should stay as defins
15:36 < jtanx> if the path does change
15:36 < jtanx> then that probably warrants a recompile anyway since stuff may have changed with how you access it
15:36 < sam_moore> Ok, should I put all the defines that you might want to adjust on a recompile in the same place?
15:37 < sam_moore> common.h?
15:37 < jtanx> what defines do we have right now
15:37 < jtanx> that may change
15:39 < sam_moore> Nothing major, I just want it to be flexible
15:39 < jtanx> hmm
15:39 < jtanx> even if you did that
15:39 < jtanx> if you needed to change the define
15:39 < jtanx> you'd probably be looking at changing hte code anyway
15:40 < sam_moore> Sure, but that doesn't mean you can't put the defines in an easy to find place
15:40 < sam_moore> For example, say someone wants to recompile this for a RPi
15:40 < jtanx> But for stuff like 'where's the pwm path'
15:40 < sam_moore> Given the trouble we had with pwm path confusion
15:41 < jtanx> I'd look in the header relevant to pin control
15:41 < sam_moore> I think it's helpful to make it easy for someone to see what we're doing
15:41 < sam_moore> I suppose
15:42 < jtanx> ok I guess it doesn't matter if it goes in common.h or not
15:42 < sam_moore> Yeah, but I think I agree with you now :P
15:42 < jtanx> ( I guess this is what ./configure and configure.h are for :P )
15:51 < sam_moore> Sigh...
15:51 < sam_moore> I put in a #warning to generate a warning if you tried to compile the software on something that isn't the BeagleBone
15:51 < sam_moore> ...
15:51 < sam_moore> And the use of #warning caused a warning
15:52 < sam_moore> warning: #warning is a GCC extension [enabled by default]
16:05 < jtanx> :p
16:08 < jtanx> because of the -pedantic flag
21:13 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
21:23 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
--- Day changed Wed Oct 02 2013
17:34 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
21:54 -!- Rowan [[email protected]] has quit [Ping timeout]
--- Day changed Thu Oct 03 2013
09:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:30 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
09:32 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
09:45 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
09:47 -!- MctxBot [[email protected]] has quit [Ping timeout]
10:26 -!- MctxBot_ is now known as MctxBot
10:37 -!- MctxBot [[email protected]] has quit ["leaving"]
10:44 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
10:45 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:45 < jtanx> finally
11:02 -!- Rowan [[email protected]] has quit [EOF From client]
12:09 < MctxBot> guh
12:09 < MctxBot> crappy laptop keeps crashing
12:17 -!- jtanx [[email protected]] has quit [Ping timeout]
12:20 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
12:20 -!- jtanx_ is now known as jtanx
12:28 < jtanx> about login_handler
12:28 < jtanx> The result from FCGI_ParseRequest
12:28 < jtanx> for string types
12:28 < jtanx> should be treated as const char*
12:29 < jtanx> I guess it really doesn't matter, unless it returns an empty string
12:29 < jtanx> it's also not true that user/pass would be of max length BUFSIZ
12:30 < jtanx> because of how it was defined, params has a max length of BUFSIZ
12:30 < jtanx> but user/pass may be anywhere in that string
12:30 < jtanx> so their max length < BUFSIZ
12:30 < jtanx> so the bounds check makes no sense
12:31 < jtanx> (sure, it prevents an infinite loop, but by that stage, you could be writing to locations where you don't want to anyway)
12:31 < jtanx> besides, FCGI_ParseRequest should guarantee that they're null terminated
12:38 < jtanx> also, whitespace (>.< :P)
12:38 < sam_moore> True, but this is the whole "defensive" programming thing where you assume that some future unspecified developer is going to do something stupid and you attempt to minimise the damage they can cause :P
12:38 < jtanx> while (*user && isspace(*user)) user++;
12:38 < jtanx> char *ptr = user;
12:38 < jtanx> while (*ptr && isalnum(*ptr)) ptr++;
12:38 < jtanx> *ptr = 0;
12:39 < jtanx> well
12:39 < jtanx> by that stage you're screwed anyway
12:39 < jtanx> not much point doing something that doesn't make sense too
12:39 < sam_moore> You're more screwed if your program is writing to undefined locations in an infinite loop than if it's writing to a finite number of undefined locations
12:39 < jtanx> still
12:39 < jtanx> at least if it's infinite
12:39 < jtanx> you'll know it crashes
12:40 < jtanx> actually that's hardly the case
12:40 < jtanx> because it will come across a zero at some point
12:40 < jtanx> more often than not
12:40 < jtanx> but anyway...
12:40 < jtanx> does valgrind pick that up?
12:41 < sam_moore> Hah
12:41 < jtanx> and to be honest, by adding the BUFSIZ check, that's implying their max length when it's actually not
12:41 < jtanx> which may be confusing in itself
12:41 < sam_moore> The operating system should pick up a segfault on the first invalid write anyway
12:41 < jtanx> unless
12:41 < jtanx> the following region is writeable too
12:42 < jtanx> eg you have a struct, members follow each other
12:43 < sam_moore> If you really want to remove the bounds check go ahead
12:43 < sam_moore> Either way that code does what it's meant to
12:43 < jtanx> ok, well yeah
12:44 < jtanx> hmm
12:44 < jtanx> problem
12:44 < jtanx> anyone can logout the currently logged in user
12:44 < jtanx> oh wait
12:45 < jtanx> sorry
12:48 < sam_moore> My network is being terrible so I can't say much
12:48 < sam_moore> One last argument in favour of the BUFSIZ check... if someone modifies the function that "should" be guaranteed to null terminate the string and doesn't... then you fall into an infinite loop
12:49 < jtanx> well that's a case of too bad
12:49 < jtanx> if it infinite loops
12:49 < jtanx> then it shows you've done something wrong, so it'd be a good case to check what you've done
12:50 < jtanx> if you hide that with a BUFSIZ check, you may not know there's a problem until later down the track
12:50 < sam_moore> If you port the code to run in a kernel module or something, it's a case of instead of getting a seg fault, you suddenly wipe out all your memory
12:50 < jtanx> with a kernel module, you'd be testing it pretty rigorously in a vm, i would think :P
12:51 < sam_moore> Yeah, but it pays not to assume things about the sanity of other programmers
12:51 < sam_moore> That's why all that extremely irritating "public, private" stuff is used
12:52 < jtanx> to be honest, I'd rather have it fail fast than come up with weird issues that may/may not happen all the time
12:52 < sam_moore> Anyway, just remove the bounds check, this is getting ridiciluos
13:31 < jtanx> hmmm
13:31 < jtanx> if ($http_cookie ~* "id=([^;] +)(?:;|$)" ) {
13:31 < jtanx>   set  $id  $1;
13:31 < jtanx> }
13:32 < jtanx> right now, only the control key can be sent as the one and only cookie
13:38 < jtanx> we could get nginx to extract the desired cookie
14:33 < jtanx> actually nah
15:02 -!- MctxBot [[email protected]] has quit [Ping timeout]
16:27 -!- jtanx [[email protected]] has quit [Connection reset by peer]
21:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:17 < jtanx> herp derp
21:17 < jtanx> was idling in mctxuwa
21:17 < jtanx> not mctxuwa_softdev
21:40 < jtanx> anyway...
21:40 < jtanx> a (the) login/logout functionality is almost done for the gui
21:40 < jtanx> to make it work, I need to add the identify module to the modules that doesn't need login
21:41 < jtanx> also, maybe fields to indicate if logged in or not when ident is called + if logged in, a 'human friendly' name to display for the user
22:34 < jtanx> ok
22:34 < jtanx> it's just about done. It auto redirects you (via javascript) to the login page if you're logged out (and vice versa)
22:34 < jtanx> this can be disabled for debugging purposes by changing mctx.debug=true in mctx.gui.js
22:34 < jtanx> it works quite well, I think
22:35 < jtanx> I still haven't implemented the whole 'friendly name' thing though
22:35 < jtanx> (e.g the 'Welcome Joe Bloggs' with the actual user name or something)
22:40 < jtanx> test at: https://mctx.us.to:8043/test/
22:42 < jtanx> except now there's a logout bug grr...
22:46 < jtanx> fixed
23:32 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Fri Oct 04 2013
14:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:50 < jtanx> so i'm in uni right now
14:50 < jtanx> and was playing with the webcam
14:50 < jtanx> If I followed this: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=35689&p=314596
14:51 < jtanx> It actually displays something and not the black image
14:51 < jtanx> the problem is that it only displays maybe the top 5% of the image
14:51 < jtanx> the rest is nothing
14:51 < jtanx> I think the next step from here is to try compiling the latest version of the uvcvideo driver ourselves
14:51 < jtanx> see if it helps
14:59 < jtanx> google 'uvcvideo beaglebone issues'
14:59 < jtanx> I wonder how we didn't see that before
15:00 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/223368.aspx
15:03 < jtanx> so many issues getting the camera to work
15:03 < jtanx> https://groups.google.com/forum/#!msg/beagleboard/sgCwaP5RVUo/aFPBOk02A7IJ
15:04 < jtanx> fwiw I'm not sure we'll be able to support cameras at all, at this rate
15:04 < jtanx> although some seem to have success with UVC video. no idea why
15:08 < jtanx> except I was testing it on angstrom 
15:08 < jtanx> when i boot off the sd card, there's no modprobe and no rmmod
15:08 < jtanx> tf
15:08 < jtanx> wtf
15:10 < jtanx> derp
15:10 < jtanx> not root
15:20 < jtanx> well crap, I got it working with ffmpeg
15:20 < jtanx>  ffmpeg -f video4linux2 -input_format mjpeg -i /dev/video0 -vcodec copy o.mjpg
15:21 < jtanx> along with the 'uvcvideo nodrop=1 timeout=5000 quriks=0x80'
15:21 < jtanx> it spits out a bunch of warnings though
15:26 < jtanx> ahh
15:26 < jtanx> if set to rawvideo
15:27 < jtanx> 640x480 is not supported
15:27 < jtanx> it must be that it's such a large resolution that only mjpg is supported
15:27 < jtanx> 320x240 works fine
15:32 < jtanx> ah well
15:32 < jtanx> that's alll for now
15:32 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
16:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
21:25 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
22:15 < jtanx> I got user friendly names working
22:15 < jtanx> 'except by user friendly I mean their usernames
22:16 < jtanx> I guess for LDAP we could look up their real name? but I don't know how to do that.
22:19 < sam_moore> I'm not sure how, but it can be done
22:20 < sam_moore> However it's probably a fair amount of work
22:20 < sam_moore> So I'd make it low priority
22:20 < jtanx> yeah ok
22:20 < sam_moore> Afterall, *they* know who they are
22:20 < sam_moore> Good work with the camera
22:20 < sam_moore> I'll be in tomorrow morning I guess
22:20 < sam_moore> Working on another project now
22:21 < jtanx> Yeah, the camera's still not finished though - it's really buggy and I only got it working with ffmpeg and not opencv
22:21 < sam_moore> Anything is progress
22:23 < sam_moore> 0/away
22:24 < sam_moore> Stupid network lag
23:13 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sat Oct 05 2013
08:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
08:44 -!- MctxBot [[email protected]] has quit [Ping timeout]
11:37 < sam_moore> Hi, I'm at Uni, but we can't access G19
11:38 < sam_moore> I was hoping Rowan, Justin, James or Callum would come in though
11:38 < sam_moore> But I guess I need to do more stuff for CITS3003 anyway
12:18 < jtanx> Sorry, I can't make it today
12:19 < jtanx> Too much crap with my CITS3242 and CITS2232 projects to deal with
12:19 < sam_moore> Ok no problem
13:16 < jtanx> james just posted some layout stuff via email
13:17 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
18:06 < jtanx> now... to do some work on this gui
21:15 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sun Oct 06 2013
08:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
11:17 < jtanx> slight problem: http://i.imgur.com/D28SHaQ.png
11:17 < jtanx> 100% cpu usage on idle
11:18 < jtanx> that memory usage too doesn't look too healthy
11:18 < sam_moore> Damn
11:20 < jtanx> I also probably figured out why valgrind crashes with the --trace-origins option - not enough memory on my system :P
11:30 < jtanx> It's probably because in read data all the cases except one have a sleep in them
11:31 < sam_moore> I'd say so
11:31 < sam_moore> There are like 8 threads
11:31 < sam_moore> We don't need 8 threads
11:39 < sam_moore> Are you in G19?
11:39 < jtanx> no
11:40 < sam_moore> Alright
11:40 < sam_moore> I suppose I should do some work on this
11:40 < sam_moore> CITS3003 is funner though
11:40 < sam_moore> I'll look into the performance issues
11:41 < jtanx> hehe
11:42 < sam_moore> My "Incident" with UWA IS is now Moderate Priority
11:42 < sam_moore> It's been assigned!
11:42 < sam_moore> I suppose I should wait for this guy to email me and say "What the hell are you on about?"
11:42 < sam_moore> (Re: Using Pheme)
11:42 < sam_moore> They classified it as a "Request for service"
11:43 < sam_moore> Which I suppose is true, except they don't really have to do anything
11:43 < jtanx> o.o
11:44 < jtanx> I hope it goes through
11:44 < sam_moore> Yes, no one's going to do a user management system
11:44 < jtanx> Yep
11:44 < sam_moore> When people complain they have nothing to do though...
11:44 < sam_moore> That's like a semester of work right there
12:40 < sam_moore> um... that image you linked
12:40 < sam_moore> That's not actually running on the BeagleBone is it?
12:40 < sam_moore> Because on the BeagleBone
12:40 < sam_moore> It's like 0.7%
12:41 < sam_moore> Actually 0.3% CPU 1.1% memory
12:50 < jtanx> no
12:50 < jtanx> that's because there's a conditional #ifdef
12:50 < jtanx> beaglebone to sleep
12:50 < jtanx> I got that condition around the wrong way
12:50 < jtanx> Initially I thought you wanted to test the absolute maximum sampling rate on the BBB
12:53 < jtanx> I just updated the repo to really remove that pwm array reference
12:54 < jtanx> (about the cpu) It's because of this: https://github.com/szmoore/MCTX3420/blob/master/server/sensor.c#L257
12:55 < jtanx> That ifdef should be removed anyway, just put in an unconditional sleep for 0.1s
12:55 < jtanx> then remove the individual sleeps from each sensor case
13:17 < sam_moore> Sure
13:17 < sam_moore> Light has been shed on the PWM thing
13:18 < sam_moore> They are using some RC circuit which I believe averages out the PWM to give you a constant signal
13:18 < sam_moore> I thought it was some kind of IC that took a PWM input
13:21 < jtanx> oh ok
13:22 < jtanx> yeah that's what I thought too
13:22 < jtanx> so no dac I guess
13:22 < jtanx> (dac ic that is)
13:24 < sam_moore> I have my doubts that electronics will be able to make this custom DAC
13:24 < sam_moore> And of course, no DAC means no Pressure control
13:24 < sam_moore> But oh well
13:24 < jtanx> ^_^
13:24 < jtanx> homebrew DAC
13:25 < jtanx> how will this ever be calibrated
13:26 < sam_moore> We should probably include a calibration routine in software
13:27 < sam_moore> I'm looking a bit more into the RT linux stuff
13:27 < sam_moore> It doesn't look too crazy
13:27 < sam_moore> Our program pretty much looks the same
13:27 < sam_moore> With a function at initialisation to set it's priority and stuff
13:27 < sam_moore> But otherwise, you just use usleep, sleep, pthreads, everything as normal
13:28 < jtanx> ok
13:28 < jtanx> as long as it works on the bbb I guess
13:30 < sam_moore> I think I should port from gettimeofday to clock_gettime too
13:35 < sam_moore> https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
13:35 < sam_moore> I'll compile us a kernel and see if it works
13:46 -!- Callum [[email protected]] has joined #mctxuwa_softdev
14:09 < sam_moore> Yeah, it looks like RT Linux won't work on the BBB
14:09 < sam_moore> Oh well
14:17 < jtanx> damn
15:34 < Callum> Hey guys, sorry i havent been in touch lately. done a bit of work on dilatometer but its not quite complete.  Uploaded what iv done but i got a test i tomorrow i should go study for now
16:29 < jtanx> hahaha
16:30 < jtanx> interactive sbd
16:31 < jtanx> hmm dialatometer
16:45 < jtanx> Justin's idea with the system diagram was pretty good
16:55 < jtanx> test run: https://mctx.us.to:8043/test/
16:55 < jtanx> no links yet
16:55 < jtanx> no descriptions either
16:55 < jtanx> logout when you're done
16:55 < jtanx> no auth so type anything you want in login field
17:24 < Callum> looks pretty good
17:27 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
17:44 -!- MctxBot [[email protected]] has quit ["leaving"]
17:47 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
17:49 -!- MctxBot [[email protected]] has quit ["again"]
18:12 < jtanx> I stuffed up /etc/fstab and now the root filesystem is readonly :(
18:19 < jtanx> ...and I just wasted time booting off ubuntu 7.04, which doesn't support ext4...
18:30 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
18:42 -!- Callum [[email protected]] has quit [Ping timeout]
18:43 -!- Callum_ is now known as Callum
18:52 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
19:30 < jtanx> I've just enabled personal webspace for everyone
19:30 < jtanx> check your emails for details
19:35 -!- Callum [[email protected]] has quit [EOF From client]
19:50 -!- Rowan [[email protected]] has quit [Ping timeout]
19:52 < jtanx> :(
21:11 < sam_moore> Cool
21:11 < sam_moore> Sorry, I'm trying to finish CITS3003
21:14 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
21:25 < jtanx> Yep no problem
21:38 < jtanx> nice: http://cssmenumaker.com
22:09 < jtanx> weird, getting http 500 when trying to access our github repo
23:16 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
23:27 -!- Rowan [[email protected]] has quit [EOF From client]
--- Day changed Mon Oct 07 2013
10:44 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
12:45 -!- callum [[email protected]] has joined #mctxuwa_softdev
12:47 < callum> you guys in g19?
14:46 -!- callum [[email protected]] has quit [Ping timeout]
14:55 -!- callum [[email protected]] has joined #mctxuwa_softdev
14:59 -!- Rowan [[email protected]] has quit [Ping timeout]
16:11 -!- callum [[email protected]] has quit [Ping timeout]
18:22 -!- jtanx [[email protected]] 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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
22:53 -!- jtanx [[email protected]] 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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Tue Oct 08 2013
18:01 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
19:37 -!- MctxBot [[email protected]] has quit [Ping timeout]
21:16 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Wed Oct 09 2013
08:29 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:20 -!- jtanx [[email protected]] has quit [Ping timeout]
09:54 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
10:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:55 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
10:56 < jtanx_> welp the usb microscope arrived
10:56 < jtanx_> it uses uvcvideo too
11:07 -!- jtanx [[email protected]] 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_ [[email protected]] has quit [Ping timeout]
13:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
14:51 -!- jtanx [[email protected]] 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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
15:54 -!- jtanx [[email protected]] 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 [[email protected]] has quit [Ping timeout]
17:52 -!- jtanx [[email protected]] 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 [[email protected]] 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 [[email protected]] has joined #mctxuwa_softdev
18:45 < jtanx> now to watch this week's lecture...
21:31 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Thu Oct 10 2013
08:11 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
13:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
23:04 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Fri Oct 11 2013
08:21 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
08:42 -!- Rowan [[email protected]] has quit [EOF From client]
09:19 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
09:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
15:09 -!- jtanx [[email protected]] 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> <!--# include file="footer.html" -->
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("<p> Something fucked up </p>")
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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sat Oct 12 2013
10:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
13:49 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
13:49 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
14:03 -!- jtanx [[email protected]] has quit [Ping timeout]
14:05 -!- MctxBot [[email protected]] has quit [Ping timeout]
14:34 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
14:39 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:46 -!- jtanx_ [[email protected]] has quit [Ping timeout]
14:47 -!- MctxBot_ [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] has quit [Connection reset by peer]
10:39 -!- MctxBot [[email protected]] 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 [[email protected]] has quit ["bye"]
--- Day changed Mon Oct 14 2013
10:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
10:03 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
19:15 -!- jtanx [[email protected]] 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 in <p> blocks
19:48 < sam_moore> Hmm, but that would make them all on new paragraphs
19:48 < jtanx> fine, <span>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 [[email protected]] has quit [Connection reset by peer]
23:13 -!- jtanx [[email protected]] 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 [[email protected]] 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__ [[email protected]] has joined #mctxuwa_softdev
19:29 -!- james__ [[email protected]] has quit [Ping timeout]
21:27 -!- James__ [[email protected]] 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__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Wed Oct 16 2013
13:39 -!- MctxBot [[email protected]] has quit [Ping timeout]
13:59 -!- jtanx [[email protected]] 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 [[email protected]] 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 [[email protected]] has quit ["brb"]
15:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
20:10 -!- MctxBot [[email protected]] has quit [Ping timeout]
21:41 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
21:56 -!- jtanx [[email protected]] has quit [Ping timeout]
23:28 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
23:28 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
--- Day changed Thu Oct 17 2013
09:16 -!- jtanx [[email protected]] 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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
13:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
14:55 -!- MctxBot [[email protected]] has quit [Ping timeout]
17:14 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
17:20 -!- MctxBot [[email protected]] has quit ["leaving"]
17:22 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
22:38 -!- jtanx [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] 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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- Day changed Sat Oct 19 2013
07:59 -!- jtanx [[email protected]] 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 [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]