--- Log opened Sat Aug 03 15:12:13 2013
15:12 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] 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_ [~androirc@101.119.30.123] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
15:45 -!- james__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] has quit [Ping timeout]
15:51 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
15:51 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] 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 [matches@motsugo.ucc.gu.uwa.edu.au] 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__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] 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 [~Callum@220-253-137-113.dyn.iinet.net.au] has joined #mctxuwa_softdev
20:38 -!- Callum [~Callum@220-253-137-113.dyn.iinet.net.au] has quit [Ping timeout]
22:01 -!- james__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] 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 [~Callum@220-253-137-113.dyn.iinet.net.au] 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__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] 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__ [~chatzilla@220-253-137-113.dyn.iinet.net.au] has joined #mctxuwa_softdev
11:45 -!- Callum [~Callum@220-253-137-113.dyn.iinet.net.au] has quit [EOF From client]
11:59 -!- james__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] 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__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] 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 git@github.com: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 git@github.com: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__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] 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_ [~justin@125.253.101.228] has joined #mctxuwa_softdev
18:36 -!- justin_ is now known as justin_kruger
18:37 -!- justin_kruger [~justin@125.253.101.228] 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__ [~chatzilla@220-253-137-113.dyn.iinet.net.au] 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__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] has joined #mctxuwa_softdev
08:13 -!- james__ [~chatzilla@CPE-58-160-245-152.wa.bigpond.net.au] has quit [Ping timeout]
10:29 -!- Callum_ [~androirc@130.95.109.236] has joined #mctxuwa_softdev
10:33 -!- Callum_ [~androirc@130.95.109.236] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
11:01 -!- james__ [~chatzilla@130.95.117.8] has joined #mctxuwa_softdev
11:19 -!- Callum [~Callum@130.95.248.224] 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 [~Callum@130.95.248.224] 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 [~justinkru@130.95.99.119] has joined #mctxuwa_softdev
15:00 -!- james__ [~chatzilla@130.95.117.8] has quit [Ping timeout]
15:34 -!- justin_kruger [~justinkru@130.95.99.119] has quit [EOF From client]
18:26 -!- Callum__ [~chatzilla@203.59.10.8] 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 [~justinkru@125.253.101.228] 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 [~justinkru@125.253.101.228] has quit [Ping timeout]
--- Day changed Tue Aug 06 2013
00:33 -!- Callum__ [~chatzilla@203.59.10.8] has quit [EOF From client]
10:48 -!- Callum__ [~chatzilla@203.59.10.8] has joined #mctxuwa_softdev
11:10 -!- james__ [~chatzilla@130.95.55.134] has joined #mctxuwa_softdev
12:05 -!- james__ [~chatzilla@130.95.55.134] has quit [Ping timeout]
12:28 -!- james__ [~chatzilla@130.95.89.85] has joined #mctxuwa_softdev
12:57 -!- james__ [~chatzilla@130.95.89.85] has quit [Ping timeout]
15:01 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
15:02 -!- justin_kruger [~justinkru@125.253.101.228] 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__ [~chatzilla@130.95.89.3] 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__ [~chatzilla@130.95.89.3] has quit [Ping timeout]
18:09 -!- RowanHeinrich [~RowanHein@124.171.231.242] has joined #mctxuwa_softdev
18:10 -!- RowanHeinrich [~RowanHein@124.171.231.242] has quit [""]
18:34 -!- Rowan [~Rowan@124.171.231.242] has joined #mctxuwa_softdev
18:35 < Rowan> test test
18:35 < Rowan> ??
18:43 < Callum__> Hey
18:56 -!- github [~github@192.30.252.50] 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 [~github@192.30.252.50] has left #mctxuwa_softdev []
18:57 -!- github [~github@192.30.252.48] 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 [~github@192.30.252.48] has left #mctxuwa_softdev []
19:41 -!- Rowan [~Rowan@124.171.231.242] has quit [Ping timeout]
23:09 -!- Callum__ [~chatzilla@203.59.10.8] has quit [EOF From client]
23:21 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
23:21 -!- justin_kruger [~justinkru@125.253.101.228] has quit [EOF From client]
--- Day changed Wed Aug 07 2013
00:24 -!- github [~github@192.30.252.60] 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 [~github@192.30.252.60] has left #mctxuwa_softdev []
00:52 -!- github [~github@192.30.252.53] 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 [~github@192.30.252.53] has left #mctxuwa_softdev []
01:00 -!- github [~github@192.30.252.48] 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 [~github@192.30.252.48] 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 [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
11:15 -!- justin_kruger [~justinkru@125.253.101.228] has quit [EOF From client]
19:36 -!- Callum__ [~chatzilla@203.59.10.8] 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__ [~chatzilla@203.59.10.8] has quit [Ping timeout]
--- Day changed Thu Aug 08 2013
08:57 -!- Callum_ [~androirc@101.119.30.118] has joined #mctxuwa_softdev
08:59 -!- Callum_ [~androirc@101.119.30.118] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
14:12 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
14:12 -!- justin_kruger [~justinkru@125.253.101.228] has quit [EOF From client]
--- Day changed Sun Aug 11 2013
11:18 -!- Callum__ [~chatzilla@124-171-171-92.dyn.iinet.net.au] has joined #mctxuwa_softdev
12:57 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
13:55 -!- justin_kruger [~justinkru@125.253.101.228] 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__ [~chatzilla@124-171-171-92.dyn.iinet.net.au] has quit [EOF From client]
--- Day changed Mon Aug 12 2013
13:10 -!- justin_kruger [~justinkru@130.95.180.147] has joined #mctxuwa_softdev
13:10 -!- justin_kruger [~justinkru@130.95.180.147] 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 [matches@motsugo.ucc.gu.uwa.edu.au] 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 [matches@motsugo.ucc.gu.uwa.edu.au] has quit [Ping timeout]
10:01 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~chatzilla@124-171-171-92.dyn.iinet.net.au] has quit [Ping timeout]
20:49 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
20:56 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
22:40 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Wed Aug 14 2013
07:58 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
15:39 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
16:22 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
16:23 -!- justin_kruger [~justinkru@125.253.101.228] has quit [EOF From client]
16:43 -!- jtanx_ [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
16:56 < jtanx_> a beagleboard
16:56 < jtanx_> hmm
16:58 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
21:34 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
22:54 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Thu Aug 15 2013
01:20 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
01:20 -!- justin_kruger [~justinkru@125.253.101.228] has quit [EOF From client]
07:58 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
13:33 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
21:34 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Fri Aug 16 2013
08:00 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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_ [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
15:01 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit [Ping timeout]
15:02 -!- jtanx_ is now known as jtanx
15:11 -!- jtanx_ [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
15:18 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["brb"]
21:55 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Sat Aug 17 2013
10:29 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
17:14 -!- justin_kruger [~justinkru@125.253.101.228] has joined #mctxuwa_softdev
17:14 -!- justin_kruger [~justinkru@125.253.101.228] has quit [EOF From client]
22:25 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
--- Day changed Sun Aug 18 2013
08:53 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
11:44 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has joined #mctxuwa_softdev
11:45 -!- jtanx_ [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
12:00 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit [Ping timeout]
12:03 -!- jtanx_ [~asfa@124-169-120-181.dyn.iinet.net.au] has quit [Ping timeout]
12:04 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
21:53 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
22:37 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
--- Day changed Mon Aug 19 2013
08:51 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
11:43 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
12:52 -!- jtanx [~asfa@130.95.129.7] has joined #mctxuwa_softdev
13:34 -!- jtanx [~asfa@130.95.129.7] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
17:42 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
21:55 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
22:15 -!- Callum [~Callum@124-171-171-92.dyn.iinet.net.au] has joined #mctxuwa_softdev
22:46 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
23:08 -!- Callum [~Callum@124-171-171-92.dyn.iinet.net.au] has quit [EOF From client]
23:11 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has joined #mctxuwa_softdev
23:14 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
23:17 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has joined #mctxuwa_softdev
23:35 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Aug 20 2013
07:44 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
08:11 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit [Ping timeout]
09:03 -!- jtanx [~asfa@130.95.113.202] has joined #mctxuwa_softdev
10:11 -!- jtanx [~asfa@130.95.113.202] has quit [Ping timeout]
10:17 -!- jtanx [~asfa@130.95.113.202] has joined #mctxuwa_softdev
13:11 -!- jtanx [~asfa@130.95.113.202] has quit [Ping timeout]
14:28 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
15:06 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
--- Day changed Wed Aug 21 2013
00:53 -!- Callum [~chatzilla@124-171-171-92.dyn.iinet.net.au] has quit [EOF From client]
07:45 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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__ [~chatzilla@130.95.133.180] has joined #mctxuwa_softdev
14:49 < james__> Hey
14:50 -!- james__ [~chatzilla@130.95.133.180] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
18:32 -!- Callum [~chatzilla@124.149.92.17] has joined #mctxuwa_softdev
19:48 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit [Ping timeout]
19:51 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
23:12 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["･_･"]
--- Day changed Thu Aug 22 2013
00:46 -!- Callum [~chatzilla@124.149.92.17] has quit [EOF From client]
08:19 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
10:00 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has left #mctxuwa_softdev []
13:19 -!- callum [~chatzilla@130.95.89.97] has joined #mctxuwa_softdev
13:20 < callum> hey
13:53 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
14:35 -!- callum [~chatzilla@130.95.89.97] has quit [Ping timeout]
15:07 -!- callum [~chatzilla@130.95.89.97] 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 [~chatzilla@130.95.89.97] has quit [EOF From client]
21:43 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] 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 [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
07:49 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
07:52 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
08:59 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
10:02 -!- jtanx [825f360d@ircip3.mibbit.com] has joined #mctxuwa_softdev
10:12 -!- jtanx [825f360d@ircip3.mibbit.com] has quit ["http://www.mibbit.com ajax IRC Client"]
10:13 -!- jtanx_ [825f360d@ircip4.mibbit.com] 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_ [825f360d@ircip4.mibbit.com] has quit ["http://www.mibbit.com ajax IRC Client"]
13:51 -!- jtanx [~asfa@124-169-120-181.dyn.iinet.net.au] has joined #mctxuwa_softdev
--- Log opened Sat Aug 24 17:07:53 2013
17:07 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] 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 [matches@motsugo.ucc.gu.uwa.edu.au] has joined #mctxuwa_softdev
11:11 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] 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 [matches@motsugo.ucc.gu.uwa.edu.au] 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 [matches@motsugo.ucc.gu.uwa.edu.au] 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 [~asfa@203-59-111-146.dyn.iinet.net.au] has joined #mctxuwa_softdev
18:08 < jtanx> :P
18:09 < jtanx> you can change the message if you want
21:03 -!- jtanx [~asfa@203-59-111-146.dyn.iinet.net.au] has quit ["brb"]
21:12 -!- jtanx [~asfa@203-59-111-146.dyn.iinet.net.au] has joined #mctxuwa_softdev
22:46 -!- jtanx [~asfa@203-59-111-146.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
--- Day changed Tue Aug 27 2013
07:40 -!- jtanx [~asfa@203-59-111-146.dyn.iinet.net.au] has joined #mctxuwa_softdev
07:54 -!- jtanx [~asfa@203-59-111-146.dyn.iinet.net.au] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
17:53 -!- jtanx [~asfa@203-59-111-146.dyn.iinet.net.au] 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 [~asfa@203-59-111-146.dyn.iinet.net.au] has quit ["bye"]