Work on test gui

[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