Automatic commit of irc logs
[matches/MCTX3420.git] / irc / log
1 --- Log opened Sat Aug 03 15:12:13 2013
2 15:12 -!- matches [[email protected]] has joined #mctxuwa_softdev
3 15:12 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
4 15:12 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
5 15:12 < matches> Good idea with the IRC channel
6 15:12 < matches> I'm Sam Moore by the way
7 15:14 < Callum_> Hey. Finally someone else 
8 15:19 < Callum_> Hmm should probably close the app so my phone has enough battery to get me home. 
9 15:21 -!- Callum_ [[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
10 15:45 -!- james__ [[email protected]] has quit [Ping timeout]
11 15:51 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
12 15:51 -!- matches [[email protected]] has left #mctxuwa_softdev []
13 --- Log closed Sat Aug 03 15:51:28 2013
14 --- Log opened Sat Aug 03 15:51:51 2013
15 15:51 -!- matches [[email protected]] has joined #mctxuwa_softdev
16 15:51 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
17 15:51 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
18 15:52 -!- matches changed the topic of #mctxuwa_softdev to: MCTX3420 UWA
19 15:52 -!- matches changed the topic of #mctxuwa_softdev to: MCTX3420 UWA - Team 4 (Software, Firmware, GUI)
20 16:40 -!- matches changed the topic of #mctxuwa_softdev to: MCTX3420 UWA - Team 4 (Software and stuff)
21 16:52 -!- james__ [[email protected]] has joined #mctxuwa_softdev
22 16:54 -!- You're now known as sam__
23 16:54 < sam__> Yuck
24 16:54 -!- You're now known as sam_moore
25 16:55 < sam_moore> That works
26 16:55 < james__> Yuck?
27 16:55 < james__> Oh right
28 16:55 < james__> all the underscores?
29 16:55 < sam_moore> Yeah
30 16:55 < james__> its a bit of a pain
31 17:01 < sam_moore> I think you might be able to comment on changes if you use github
32 17:01 < sam_moore> I'll see if I can copy the repository there
33 17:01 < james__>  you should be able to
34 17:01 < sam_moore> It does seem useful
35 17:01 < james__> its what it waas designed for really
36 17:01 < sam_moore> Yeah, gitweb is a bit more limited
37 17:02 < james__> Yeah.  Or at least the features aren't as easily accesible as in github
38 17:10 < sam_moore> I'll clone the repository into github now
39 17:24 < james__> Need to be logged in but it looks like you can comment
40 18:13 -!- Callum [[email protected]] has joined #mctxuwa_softdev
41 20:38 -!- Callum [[email protected]] has quit [Ping timeout]
42 22:01 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
43 22:15 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
44 --- Day changed Sun Aug 04 2013
45 10:43 -!- Callum [[email protected]] has joined #mctxuwa_softdev
46 10:47 < Callum> morning
47 10:49 < sam_moore> Hi
48 10:52 < Callum> What is there we need to get done? i haven't really done anything yet
49 10:53 < sam_moore> We need to write a progress report on what we need to get done :P
50 10:53 < Callum> Thats the other thing i wanted to know, is the progress report per person or per group?
51 10:53 < sam_moore> It's per group, and it only has to be one page
52 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
53 10:54 < Callum> ok, that makes things a lot easier then
54 10:54 < sam_moore> We are meant to have our own technical diaries with handwritten notes
55 10:54 < Callum> yea saw that as well
56 10:55 < sam_moore> So, at the meeting we sort of worked out a vague idea of what systems we'll need
57 10:55 < Callum> yea had a read through the meeting notes
58 10:56 < Callum> seemed like a solid start
59 10:56 < sam_moore> Yes, I think I'll do a block diagram about it
60 10:56 < sam_moore> Since I actually have a raspberry pi I've been playing with it
61 10:57 < sam_moore> No one's really done that much though, to be fair our group was only completely formed by Friday
62 10:57 < Callum> Well, I'm the guy that moved into the group :p
63 10:58 < sam_moore> Is there anything in particular you'd like to work on?
64 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
65 10:59 < Callum> well, any hardware other than what we did in embedded
66 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
67 11:03 < Callum> Yea true. Might have a play around with git sometime soon to get used to it
68 11:03 < sam_moore> Oh, something I listed in an email was image processing, that will be important
69 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
70 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
71 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
72 11:37 -!- james__ [[email protected]] has joined #mctxuwa_softdev
73 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
74 11:42 < Callum> And hey James
75 11:43 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
76 11:45 -!- Callum [[email protected]] has quit [EOF From client]
77 11:59 -!- james__ [[email protected]] has quit [Ping timeout]
78 12:09 < sam_moore> Callum__: Ok, send it to me
79 12:11 < sam_moore> If you have github accounts let me know those as well
80 12:11 -!- james__ [[email protected]] has joined #mctxuwa_softdev
81 12:11 < james__> Hey
82 12:12 < sam_moore> Hi
83 12:12 < sam_moore> You guys can't see what's written in the channel whilst you're not in it, right?
84 12:12 < james__> How are things
85 12:12 < james__> Nope
86 12:12 < james__> Its only once you log in  that you can read it
87 12:13 < sam_moore> I'm messing around with git a bit, I've sent an email about the progress report
88 12:13 < james__> Unless you log it there isn't any way to go back to previous convos
89 12:13 < sam_moore> I'd like to meet at 2pm on Monday if that's possible
90 12:13 < james__> sounds good
91 12:13 < sam_moore> I'm running irssi in screen on a server, so I'll have everything logged
92 12:13 < sam_moore> I'll look into making the logs available on git
93 12:14 < Callum__> think anyone would care if i go to G19 without the safety meeting? not like we're actually doing anything.
94 12:14 < james__> i'm using chatzilla so there is an inbuilt log function
95 12:15 < james__> Don't know tbh
96 12:15 < sam_moore> Callum__: No, but just try not do anything unsafe or the rest of us will get the blame :P
97 12:15 < Callum__> well, we could just meet somewhere else. Not like we need to go there
98 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.
99 12:16 < sam_moore> Ok, what's another good place?
100 12:16 < james__> No idea
101 12:16 < james__> The lab is kinda nice and quite/out of the way
102 12:16 < Callum__> ok well it should be fine. If it's a suitable meeting location than just go with it.
103 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.
104 12:17 < Callum__> Yea. just making sure it wont be a problem
105 12:18 < Callum__> Im going to get some lunch. 
106 12:40 < sam_moore> You need to use [email protected]:matchesucc/MCTX3420.git to commit using your ssh key
107 12:41 < sam_moore> If you give me your username, I think you can use https://github.com/matchesucc/MCTX3420.git
108 12:41 < sam_moore> You should be able to commit to git.ucc with your ssh key
109 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.
110 12:43 < Callum__> username: Callum-
111 12:45 < sam_moore> Right, before you commit your changes, pull from the server
112 12:45 < sam_moore> If your repository is "up to date" with the server and you make changes, it is really easy
113 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
114 12:47 < sam_moore> We'll probably have to deal with it at some point.
115 12:48 < Callum__> how do you pull from github>
116 12:51 < sam_moore> Not sure how you do it in the gui, is there a "pull" or "fetch" button
117 12:52 < Callum__> not that i can see
118 12:52 < sam_moore> Hang on, I'll start windows and see if I can work out how to do it
119 12:53 < james__> are you logged in?
120 12:53 < sam_moore> Yes
121 12:53 < sam_moore> Cool, you can even edit the files entirely from github
122 12:54 < Callum__> you can?
123 12:54 < sam_moore> Well, I can
124 12:54 < sam_moore> I added Callum- as a collaborator; can you see the repository?
125 12:55 < Callum__> i could see it before
126 12:55 < Callum__> wait hang on
127 12:56 < james__> can you add me aswell?
128 12:56 < james__> username: firefields
129 12:57 < Callum__> i can edit it from the browser
130 12:57 < sam_moore> Done
131 12:57 < sam_moore> Excellent, that's a start
132 12:59 < james__> I can comment
133 13:00 < sam_moore> The browser editor actually looks pretty good
134 13:01 < sam_moore> Hmm
135 13:01 < sam_moore> We need to be able to pull from github to our own machines though
136 13:01 < sam_moore> So we can actually run code
137 13:02 < sam_moore> I can do it myself using the command line
138 13:02 < sam_moore> I'll see how to do it using the GUI
139 13:03 < james__> I am having a look through the documentation now trying to find it
140 13:07 < sam_moore> I wonder what happens when two people edit a file at the same time
141 13:07 < james__> Lets edit the readme?
142 13:08 < sam_moore> Alright.
143 13:08 < james__> I am currently editing
144 13:08 < james__> Can you get in?
145 13:09 < sam_moore> Yes, and it looks the same
146 13:09 < sam_moore> Make some changes and commit it, then I'll go and we'll see what happens
147 13:09 < james__> Done
148 13:09 < sam_moore> It says that you have committed since I started editing
149 13:10 < sam_moore> Whoops, but I could still overwrite it
150 13:11 < sam_moore> Ok, at least it gives us a warning, that's nice
151 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
152 13:11 < james__> Also
153 13:11 < james__> if you look in history my changes are still there
154 13:11 < sam_moore> Yeah, that's nice
155 13:12 < sam_moore> And I think we can go back to them
156 13:12 < james__> I am reading about this fork and pull method as well.  Might work well
157 13:13 < james__> Essentially you fork the repo. Make changes then request for it to be pulled back into the master repo 
158 13:13 < sam_moore> Yes, that will likely be the best way to go about it.
159 13:13 < james__> That way all changes can be viewed and then confirmed before going into the master copy
160 13:15 < james__> https://help.github.com/articles/fork-a-repo
161 13:15 < james__> and this https://help.github.com/articles/using-pull-requests
162 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
163 13:17 < Callum__> might just end up learning how to do it all from command line anyway
164 13:17 < sam_moore> All the tutorials seem to give the command line stuff
165 13:17 < Callum__> yea
166 13:17 < Callum__> suppose you could use the gui just to look at whats there
167 13:17 < sam_moore> `git add remote github [email protected]:matchesucc/MCTX3420.git`
168 13:17 < sam_moore> `git pull github master`
169 13:17 < sam_moore> Make changes
170 13:17 < sam_moore> `git add .`
171 13:18 < sam_moore> `git commit`
172 13:18 < sam_moore> `git push github master`
173 13:18 < sam_moore> Well, that's just directly going to the repository without forking it
174 13:19 < Callum__> is the add thing for staging?
175 13:19 < sam_moore> Yeah; you have to tell it what changes to stage to the commit
176 13:19 < Callum__> yea
177 13:19 < sam_moore> I think there is an option to automatically add all changed files
178 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
179 13:20 < james__> Do we want to fork first
180 13:20 < sam_moore> Probably
181 13:20 < james__> That way someone can't make a change that is incorrect into the master
182 13:21 < sam_moore> Yes, this sounds good
183 13:22 < sam_moore> It won't let me fork it (probably because I'm the "owner")
184 13:24 < james__> I have forked succesfully
185 13:25 < james__> maybe branch?
186 13:25 < sam_moore> No, branches are different
187 13:25 < james__> Right...
188 13:25 < james__> well i made a branch for you? :P
189 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
190 13:27 < sam_moore> Yeah, we don't want to use branches just yet
191 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
192 13:28 < sam_moore> For example: You have some really badly written code, but it does what it's meant to do
193 13:28 < sam_moore> So you make a branch "Improve networking code" or something like that
194 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
195 13:30 < james__> Fair enough. I think i have made a pull request...
196 13:30 < sam_moore> Cool
197 13:31 < sam_moore> Now it should be in the main repository
198 13:32 < james__> yeah. worked
199 13:32 < sam_moore> I show up as the author of your changes, which is a bit silly
200 13:33 < Callum__> firefields opened this pull request 15 hours ago
201 13:33 < Callum__> what
202 13:34 < sam_moore> Is the clock on your local machine correct?
203 13:34 < Callum__> yea
204 13:34 < Callum__> matchesucc merged 1 commit into matchesucc:master  from firefields:master  2 minutes ago
205 13:34 < Callum__> it also says that
206 13:34 < james__> Right.... Thats weird
207 13:35 < sam_moore> You guys should also be able to merge the pull requests, since you're collaborators
208 13:36 < Callum__> alright
209 13:36 < james__> Yeah. Should be able to
210 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
211 13:36 < james__> pretty much
212 13:36 < sam_moore> Cool
213 13:36 < sam_moore> We should put this in the progress report
214 13:37 < Callum__> Yea, detailing how we plan to collaborate the code
215 13:38 < sam_moore> So, should I put our IRC channel log into git?
216 13:39 < Callum__> probably a good idea
217 13:39 < sam_moore> That way people who weren't in the channel can read conversations they missed 
218 13:39 < Callum__> unlikely be that useful but it would be good to have everything archived
219 13:42 < james__> Its always good to have everything archived
220 13:47 < Callum__> so noone else getting weird timestamps on github
221 13:47 < james__> not that i can see
222 13:48 < sam_moore> No, they all make sense to me
223 13:48 < Callum__> also my forked repo doesnt have the updated readme
224 13:48 < Callum__> iv added the upstream and tried fetch upstream and doesnt seem to do anything
225 13:48 < sam_moore> Try merging after the fetch
226 13:48 < sam_moore> fetch + merge = pull
227 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
228 13:49 < Callum__> yea, i got that. how do i do the merge?
229 13:50 < sam_moore> git merge upstream/master
230 13:51 < Callum__> yup that worked
231 13:51 < sam_moore> The GUI seems really terrible, I have no idea how to do this stuff with it
232 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
233 13:52 < Callum__> yea
234 13:52 < james__> Its easier to comment etc
235 13:53 < james__> But some of the functionality is horribly buried
236 13:53 < sam_moore> Do you get a text editor in the terminal when you want to commit?
237 13:54 < sam_moore> Oh well, whatever people find easiest
238 14:09 < Callum__> alright well i just submitted a pull request and accepted it
239 14:10 < sam_moore> Yep
240 14:10 < sam_moore> Callum- authored in 15 hours
241 14:11 < sam_moore> ?
242 14:11 < Callum__> ahahahahahaah
243 14:11 < sam_moore> Are you from the future?
244 14:11 < sam_moore> Does IRC mess with the space time continuum
245 14:11 < Callum__> it says 15 minutes ago for me, but the rest are 17 hjours ago
246 14:11 < Callum__> i must be from the future :o
247 14:12 < sam_moore> Someone's clock is out of skew
248 14:13 < sam_moore> That is really wierd
249 14:13 < sam_moore> You merged the pull request... before the file was changed... according to this history
250 14:14 < sam_moore> Oh!
251 14:14 < sam_moore> Is it because github is based in the US
252 14:14 < Callum__> but for you all the times are right apart from mine?
253 14:14 < Callum__> and for me all the times are wrong but mine
254 14:15 < sam_moore> Well it's only showing relative times
255 14:15 < Callum__> or do you get weird results from james as well?
256 14:15 < sam_moore> James times look reasonable
257 14:15 < Callum__> hmm. weird
258 14:15 < sam_moore> But notice how a lot of our stuff is on 3rd August, it's actually the 4th today
259 14:16 < Callum__> hmm yea
260 14:17 < sam_moore> I kind of think we should fix this, it's not a major issue but it will certainly be confusing
261 14:18 < sam_moore> Hey, wierd, the times look sensible in git.ucc
262 14:18 < sam_moore> http://git.ucc.asn.au/?p=matches/MCTX3420.git;a=summary
263 14:19 < Callum__> yea agreed 
264 14:19 < Callum__> and that is kinda weird
265 14:20 < Callum__> i cant seem to find anything in account settings for a timezone
266 14:21 < Callum__> Anything else we need done by tomorrow? because i have a bunch of other stuff I'd like to get done
267 14:21 < sam_moore> While you're in account settings, you can set your author name for commits
268 14:22 < sam_moore> No, there's nothing urgent at this stage
269 14:22 < sam_moore> It's only the first week, and we only need 1 page
270 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
271 14:22 < Callum__> Yea just we need to make sure we have enough for 1 page
272 14:23 < Callum__> hmm, true i suppose. set up IRC + git repo + discussed an outline on what is going to be required
273 14:24 < Callum__> Tbh he'l likely be happy if we just give him a summary of those meeting minutes
274 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
275 14:25 < sam_moore> Ok, thanks
276 14:26 < sam_moore> The first automatic commit of the irc logs seems to have worked!
277 14:26 < sam_moore> It also copies everything to git.ucc so we have a backup
278 14:26 < Callum__> nice
279 14:27 < sam_moore> The times might be correct as well :P
280 14:27 < Callum__> was just like "where is it? " then i realise i was looking at my forked repo
281 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
282 14:27 < sam_moore> Actuall I'll just remove everyone's keys to stop that from happening
283 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
284 14:28 < Callum__> oh wow. the logs go all the way back to when you first connected
285 14:28 < Callum__> haha
286 14:30 < Callum__> and according to me the logs were commited 15 hours ago
287 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
288 14:33 < Callum__> yea
289 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
290 14:36 < sam_moore> I think I have a lot of work to do as well, I should do something for another unit
291 14:36 < sam_moore> See you later
292 14:36 < Callum__> later
293 15:32 < sam_moore> Ok, so pretty much anyone can comment on our stuff, and pretty much anyone can submit bug reports
294 15:32 < sam_moore> I'm going to say that's useful, and we should tell all the other teams about it
295 15:33 < sam_moore> Also I was supposed to go do something else, whoops
296 16:30 -!- james__ [[email protected]] has quit [Ping timeout]
297 18:35 < sam_moore> I changed my username because someone pointed out it sounds like "matches succ"
298 18:35 < sam_moore> But the old links should redirect
299 18:35 -!- justin_ [[email protected]] has joined #mctxuwa_softdev
300 18:36 -!- justin_ is now known as justin_kruger
301 18:37 -!- justin_kruger [[email protected]] has quit [EOF From client]
302 18:37 < sam_moore> Whoops
303 20:21 < Callum__> whoops?
304 21:20 < sam_moore> EOF From client
305 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
306 21:34 < sam_moore> Ah, I can't, because basically they have total control over their own fork
307 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.
308 21:50 -!- Callum__ [[email protected]] has quit [Ping timeout]
309 --- Day changed Mon Aug 05 2013
310 00:00 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
311 07:51 -!- james__ [[email protected]] has joined #mctxuwa_softdev
312 08:13 -!- james__ [[email protected]] has quit [Ping timeout]
313 10:29 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
314 10:33 -!- Callum_ [[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
315 11:01 -!- james__ [[email protected]] has joined #mctxuwa_softdev
316 11:19 -!- Callum [[email protected]] has joined #mctxuwa_softdev
317 11:19 < Callum> hallo
318 11:29 < sam_moore> Hi
319 11:30 < sam_moore> I've spoken to Omid from the electronics team, they are in charge of the "microcontroller"
320 11:31 < sam_moore> Apparently they think a raspberry pi is a good choice
321 11:31 < sam_moore> I told him we thought we might need a lower level device to do the ADC/DAC in particular
322 11:32 < sam_moore> But they seem to think a raspberry pi by itself will work
323 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
324 11:33 < sam_moore> But if we agree we want a raspberry pi it probably won't be an issue
325 11:33 < sam_moore> Also apparently the unit coordinators recommended the raspberry pi as well
326 11:34 < Callum> Yea he did
327 11:34 < james__> Well we are using the raspberry pi as a server
328 11:34 < james__> And we can bootstrap microcontrollers onto it
329 11:34 < james__> So i guess we are in charge of the pi
330 11:35 < james__> And the are in charge of the hardware around it
331 11:35 < james__> *they
332 11:35 < sam_moore> Seems logical
333 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
334 11:36 < sam_moore> I kind of added some thoughts of my own
335 11:38 < sam_moore> Hopefully it makes sense
336 11:41 < sam_moore> If either of you gets time, would you like to start typing some of the progress report?
337 11:51 -!- Callum [[email protected]] has quit [Ping timeout]
338 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
339 11:52 < sam_moore> I'm pretty sure we do
340 11:52 < sam_moore> Hang on
341 11:53 < sam_moore> All teams are expected to report next monday (see the report format in the unit outline/overview).
342 11:53 < sam_moore> All teams must review their sub-system and provide high level detail of what is required.
343 11:54 < sam_moore>  All team must take an integrated approach. (I assume this means we have to start talking to other teams ASAP)
344 11:54 < sam_moore> I think the block diagram is a good start for the high level detail
345 11:54 < sam_moore> Then make some notes about how we're collaborating using git
346 11:55 < james__> git and irc
347 11:55 < sam_moore> We should decide whether Rowan or I will be the meeting convener
348 11:56 < james__> I think you
349 11:56 < james__> Just because you actually know what is going on
350 11:56 < sam_moore> Yes, I'm happy to do it and I think I can do a good job
351 11:56 < sam_moore> I just don't want to try and take over the group or something
352 11:56 < sam_moore> I have a good idea of what's going on, but we'll still need everyone to contribute
353 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
354 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
355 11:58 < sam_moore> Ok, thanks, if everyone agrees we'll tell Rowan that when we meet
356 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
357 11:59 < james__> True
358 12:00 < james__> there isn't anything that says he can't talk to others
359 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
360 12:00 < sam_moore> Anyway, I should do some other work, see you at 2pm
361 12:01 < james__> Yeah might be worth it.  Gives everyone a taster
362 12:01 < james__> okay see you then
363 14:45 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
364 15:00 -!- james__ [[email protected]] has quit [Ping timeout]
365 15:34 -!- justin_kruger [[email protected]] has quit [EOF From client]
366 18:26 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
367 20:38 < sam_moore> I'm going to try using the GitHub issues and milestones thing
368 20:39 < sam_moore> It might help with keeping track of what we need to do and what we've done
369 20:45 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
370 20:50 < sam_moore> I think we had some difficulty setting specific goals for this week
371 20:50 < sam_moore> I can try and put together some longer term goals as a start, if that's helpful
372 20:51 < sam_moore> Hmm
373 20:52 < sam_moore> We weren't given a lot of requirements that the guy was asking us about
374 21:06 < sam_moore> So the most important task seems to be "determine those requirements"
375 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
376 21:32 < Callum__> Sam are you talking to yourself or am i not just seeing the other messages?
377 21:35 < sam_moore> Yeah, just ranting
378 21:36 < sam_moore> Well if you read the messages, then I was talking to you :P
379 21:37 < Callum__> haha just they seemed like they were structured like you were responding to someone
380 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
381 21:39 < sam_moore> Or even if they don't need a reply
382 21:45 < Callum__> Fair enough
383 21:51 -!- justin_kruger [[email protected]] has quit [Ping timeout]
384 --- Day changed Tue Aug 06 2013
385 00:33 -!- Callum__ [[email protected]] has quit [EOF From client]
386 10:48 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
387 11:10 -!- james__ [[email protected]] has joined #mctxuwa_softdev
388 12:05 -!- james__ [[email protected]] has quit [Ping timeout]
389 12:28 -!- james__ [[email protected]] has joined #mctxuwa_softdev
390 12:57 -!- james__ [[email protected]] has quit [Ping timeout]
391 15:01 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
392 15:02 -!- justin_kruger [[email protected]] has quit [EOF From client]
393 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)
394 15:30 -!- james__ [[email protected]] has joined #mctxuwa_softdev
395 15:39 < Callum__> hey
396 15:39 < james__> what up
397 15:39 < sam_moore> Hi
398 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)
399 15:40 < sam_moore> Callum__: I think so
400 15:40 < james__> As far as i understand it yes
401 15:40 < Callum__> plus just booted up ubuntu on laptop. havent touched it since i did C programming a year ago xD
402 15:40 < sam_moore> It would also be nice to just have unprocessed images streamed to the GUI
403 15:40 < Callum__> yea what i was thinking
404 15:41 < Callum__> firstly, i can look into only processing a portion of the image, so we could get away with a larger resolution
405 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
406 15:41 < Callum__> and openCV has a couple of algorithms to detect edges
407 15:41 < Callum__> so will likely look into one or 2 of those
408 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
409 15:42 < sam_moore> Plus, if we really care about performance, the apache2 webserver has a lot of features we don't care about
410 15:42 < james__> As long as i can access the raw files etc i should be able to display it via a gui
411 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
412 15:43 < sam_moore> Yes, that sounds good
413 15:44 < Callum__> responding to who? me or james?
414 15:44 < sam_moore> Um... both now
415 15:44 < Callum__> haah
416 15:45 < sam_moore> Anyway, I've realised that our software will place an upper limit on the quality of the sensors
417 15:45 < james__> true
418 15:45 < sam_moore> Since we weren't given a requirement on quality, we should aim to get it as high as feasible
419 15:45 < sam_moore> But sensors group needs to have some idea of the upper limit that our software will place on quality
420 15:45 < Callum__> yea. 
421 15:46 < james__> Start simple and ramp it up until the hardware breaks?
422 15:46 < sam_moore> No point streaming 1000 images a second if the JavaScript GUI can't send requests that fast.
423 15:46 < sam_moore> Yep.
424 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
425 15:47 < james__> yeah. break it down into code and test code?
426 15:48 < sam_moore> Maybe?
427 15:49 < sam_moore> Well, we've got a high level idea of the software
428 15:49 < sam_moore> The first tasks should be "decide on the best software implementation of each level"
429 15:49 < sam_moore> To do that we need to test some minimalistic implementations
430 15:50 < Callum__> yea
431 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"
432 15:51 < sam_moore> And "Determine upper limit on data transfer rate through software systems"
433 15:51 < sam_moore> The second one might take a bit longer.
434 15:52 < Callum__> githubs down for maintenance. hahah
435 15:52 < sam_moore> That happened like 2 seconds after I submitted a comment on the CGI stuff
436 15:53 < sam_moore> For a while it was showing me a Unicorn (?)
437 15:53 < Callum__> yea i got that before
438 15:53 < Callum__> when trying to access on my laptop
439 15:53 < sam_moore> Well... we have the git.ucc server
440 15:54 < sam_moore> But I was starting to like the Issues and Comments and all those actual features
441 15:54 < Callum__> hmm. doubt it will be down for long. will have to see
442 16:10 < Callum__> back up
443 17:22 -!- james__ [[email protected]] has quit [Ping timeout]
444 18:09 -!- RowanHeinrich [[email protected]] has joined #mctxuwa_softdev
445 18:10 -!- RowanHeinrich [[email protected]] has quit [""]
446 18:34 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
447 18:35 < Rowan> test test
448 18:35 < Rowan> ??
449 18:43 < Callum__> Hey
450 18:56 -!- github [[email protected]] has joined #mctxuwa_softdev
451 18:56 -github:#mctxuwa_softdev- [MCTX3420] none pushed 2 new commits to master: http://git.io/ZDMvew
452 18:56 -github:#mctxuwa_softdev- MCTX3420/master 64b0cd9 Sam Moore: Investigate software for interfacing with hardware via HTTP requests...
453 18:56 -github:#mctxuwa_softdev- MCTX3420/master 5afaa23 Sam Moore: Merge branch 'master' of github:szmoore/MCTX3420
454 18:56 -!- github [[email protected]] has left #mctxuwa_softdev []
455 18:57 -!- github [[email protected]] has joined #mctxuwa_softdev
456 18:57 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/1nMEMA
457 18:57 -github:#mctxuwa_softdev- MCTX3420/master 9579cea Sam Moore: Makefile for webserver test...
458 18:57 -!- github [[email protected]] has left #mctxuwa_softdev []
459 19:41 -!- Rowan [[email protected]] has quit [Ping timeout]
460 23:09 -!- Callum__ [[email protected]] has quit [EOF From client]
461 23:21 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
462 23:21 -!- justin_kruger [[email protected]] has quit [EOF From client]
463 --- Day changed Wed Aug 07 2013
464 00:24 -!- github [[email protected]] has joined #mctxuwa_softdev
465 00:24 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/5DEPzw
466 00:24 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
467 00:24 -!- github [[email protected]] has left #mctxuwa_softdev []
468 00:52 -!- github [[email protected]] has joined #mctxuwa_softdev
469 00:52 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/r6aFJw
470 00:52 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
471 00:52 -!- github [[email protected]] has left #mctxuwa_softdev []
472 01:00 -!- github [[email protected]] has joined #mctxuwa_softdev
473 01:00 -github:#mctxuwa_softdev- [MCTX3420] none pushed 1 new commit to master: http://git.io/eZPWcQ
474 01:00 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
475 01:00 -!- github [[email protected]] has left #mctxuwa_softdev []
476 10:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
477 11:15 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
478 11:15 -!- justin_kruger [[email protected]] has quit [EOF From client]
479 19:36 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
480 20:43 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
481 20:45 -github:#mctxuwa_softdev- [MCTX3420] none pushed 3 new commits to master: http://git.io/Dhb-Fg
482 20:45 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
483 20:45 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
484 20:45 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
485 20:45 -github:#mctxuwa_softdev- [MCTX3420] none pushed 3 new commits to master: http://git.io/Dhb-Fg
486 20:45 -github:#mctxuwa_softdev- MCTX3420/master fe2fc11 Sam Moore: More work on webserver test...
487 20:45 -github:#mctxuwa_softdev- MCTX3420/master e615433 Sam Moore: Add necessary HTTP response headers...
488 20:45 -github:#mctxuwa_softdev- MCTX3420/master b101617 Sam Moore: Automatic commit of irc logs
489 20:46 < sam_moore> Whoops, I was trying to make it less spammy and ended up making it spam us
490 20:53 < Callum__> haha nice work
491 20:58 < sam_moore> I have a minimal web server in C done
492 20:58 < sam_moore> It was surprisingly easy actually
493 21:05 -github:#mctxuwa_softdev- [MCTX3420] none pushed 2 new commits to master: http://git.io/Tui0FA
494 21:05 -github:#mctxuwa_softdev- MCTX3420/master c1321a7 Sam Moore: Test webserver with minimalist JavaScript...
495 21:05 -github:#mctxuwa_softdev- MCTX3420/master 1b2939d Sam Moore: Merge branch 'master' of github:szmoore/MCTX3420...
496 21:07 < sam_moore> Hooray, more spam
497 21:07 < sam_moore> Maybe I should just turn that off.
498 21:35 < Callum__> Maybe, its kinda goods to know when people commit things though, restricted to one line would be good
499 23:23 -!- Callum__ [[email protected]] has quit [Ping timeout]
500 --- Day changed Thu Aug 08 2013
501 08:57 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
502 08:59 -!- Callum_ [[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
503 14:12 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
504 14:12 -!- justin_kruger [[email protected]] has quit [EOF From client]
505 --- Day changed Sun Aug 11 2013
506 11:18 -!- Callum__ [[email protected]] has joined #mctxuwa_softdev
507 12:57 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
508 13:55 -!- justin_kruger [[email protected]] has quit [EOF From client]
509 14:09 < Callum__> actually so much work to do already. 
510 14:47 < sam_moore> Yep
511 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
512 15:25 < sam_moore> We can always flesh out people's reports with graphs and stuff
513 15:27 < Callum__> well we doing 1 per person or group?
514 15:29 < sam_moore> 1 per person is the safest way to go I think
515 15:29 < sam_moore> We can always summarise them
516 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
517 15:30 < sam_moore> Yep
518 15:31 < Callum__> so they might end up making it 1 per person anyway. 
519 15:31 < Callum__> not very well thought out either way
520 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.
521 15:32 < Callum__> Yea, agreed thats the best way to go about it. Unless they complain about it being too long
522 15:32 < sam_moore> That's why we include a summary :P
523 15:33 < sam_moore> Although, it might be difficult to make the summary actually summarise things, since everyone's already using pretty concise summaries
524 15:33 < sam_moore> Oh well, writing more stuff is safer to start with.
525 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..
526 15:34 < sam_moore> Ah crap, I forgot about the book
527 15:34 < Callum__> haha
528 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...
529 15:35 < sam_moore> I suppose in the "Real World" you have to do stuff like this
530 15:35 < Callum__> yea true 
531 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?
532 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
533 18:27 < sam_moore> Then there are some things I need to ask everyone about to progress with my part of the code
534 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
535 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
536 18:29 < sam_moore> But to do that we'd need everyone to use the same language
537 18:30 < sam_moore> Also we need to start thinking about the structure of the system in a bit more detail
538 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)
539 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
540 18:34 < Callum__> yea
541 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
542 18:35 < sam_moore> Anyway, good luck, see you tomorrow
543 18:36 < Callum__> Alright, cya tomorrow them
544 23:08 -!- Callum__ [[email protected]] has quit [EOF From client]
545 --- Day changed Mon Aug 12 2013
546 13:10 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
547 13:10 -!- justin_kruger [[email protected]] has quit [EOF From client]
548 --- Log closed Tue Aug 13 07:49:14 2013
549 --- Log opened Tue Aug 13 07:55:27 2013
550 07:55 -!- sam_moor1 [[email protected]] has joined #mctxuwa_softdev
551 07:55 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
552 07:55 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
553 07:59 -!- sam_moore [[email protected]] has quit [Ping timeout]
554 10:01 -!- Callum [[email protected]] has joined #mctxuwa_softdev
555 10:01 < Callum> So apparently we have a new member..
556 10:12 < sam_moor1> Yep, Jeremy Tan, apparently he's doing CS as well?
557 10:13 < sam_moor1> So, with the two sources of confusion we have so far...
558 10:13 < sam_moor1> 1. The Camera - Adrian thinks we need one, Sensors team doesn't, everyone needs to recheck calculations
559 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
560 10:14 < Callum> well, they may be right in saying we may not be able to do any proper processing on it
561 10:14 < Callum> but we will need one to relay whats actually HAPPENING in the system
562 10:14 < Callum> surely the sensors team see that..
563 10:15 < sam_moor1> I guess, I told them in their meeting it would probably be useful
564 10:15 < sam_moor1> Anyway...
565 10:15 < sam_moor1> We all got in trouble for not communicating between teams well enough
566 10:15 < sam_moor1> So now the 9am session is for teams to communicate (at least one member is meant to go)
567 10:15 < Callum> how many people went to the lecture?
568 10:15 < sam_moor1> About 6
569 10:16 < Callum> haha
570 10:16 < sam_moor1> I think only one team didn't have a representative, electronics?
571 10:16 < Callum> hmm. thats not too bad then. 
572 10:16 < Callum> but still, not really our fault communication was poor. we attempted to set up meetings and to convene with others.
573 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)
574 10:17 < sam_moor1> Yeah, I really think this project needed some kind of direction at the start
575 10:17 < sam_moor1> I think that's what we're going to have to do
576 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"
577 10:18 < sam_moor1> At least that's the vibe I got from Adrian
578 10:18 < sam_moor1> Also what happened to my name
579 10:18 < Callum> hmm ok. it would help if we had the team convener meeting to do that
580 10:18 -!- You're now known as sam_moore
581 10:19 < Callum> and no idea
582 10:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
583 10:20 < sam_moore> Also, so far we've neglected physical details a bit
584 10:20 < sam_moore> Lastly, we need to start ordering things as soon as possible
585 10:21 < sam_moore> Oh, and we (as in, all teams) are supposed to have a schedule of tasks agreed upon
586 10:21 < sam_moore> Right, I need to have lunch
587 10:21 < sam_moore> *breakfast
588 10:22 < sam_moore> Then I guess I can panic some more
589 10:23 < Callum> haha. we'v only had 2 weeks to work on this really. We can pull it back.
590 10:24 < sam_moore> The scary part is where they do a very similar project every year and no one ever succeeds :S
591 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
592 10:25 < sam_moore> Oh well, they can't just fail the entire class
593 10:25 < sam_moore> It would be nice to actually succeed though
594 10:30 < Callum> Yea, well even if it doesnt work a lot of the marking will come from the shit like the diary
595 10:30 < Callum> but yes, it would be nice to see a can go boom
596 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
597 11:58 < sam_moore> Just take the images and save them to a file for a start I guess
598 12:00 < Callum> alright. 
599 12:13 < Callum> I might reinstall linux on my laptop, stick with ubuntu or go debian?
600 12:51 < sam_moore> I'd recommend debian
601 12:51 < sam_moore> It's not that much harder to use, but it's closer to raspian
602 13:06 < Callum> alright. any port better to use?
603 13:15 < sam_moore> Oh, stick with "stable"
604 13:15 < sam_moore> ie: Wheezy
605 13:16 < sam_moore> No matter what you do, do NOT get "Sid"
606 13:18 < Callum> nah i meant the architecture
607 13:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
608 13:20 < jtanx> yallo
609 13:20 < Callum> hey
610 13:21 < sam_moore> Hi
611 13:23 < jtanx> i should say that right now I cant access g19 because I haven't gone through the safety induction yet
612 13:23 < sam_moore> Callum: The architecture shouldn't matter too much
613 13:24 < Callum> we can let you in. As long as you don't do anything stupid it will be fine 
614 13:24 < Callum> alright
615 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
616 13:25 < Callum> true
617 13:25 < sam_moore> It's just nice to be able to run test software in debian
618 13:25 < jtanx> so do you have access to an/the RPi and the other microcontrollers, or is that tba
619 13:26 < sam_moore> We have access to "an" (not "the") RPi
620 13:26 < Callum> rowan has an arduino too
621 13:26 < sam_moore> Ah, that's good
622 13:26 < Callum> atleast i think he said he did
623 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)
624 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
625 13:27 < sam_moore> Adrian said to allow for 6 weeks ordering time
626 13:28 < sam_moore> Yeah, the entire class needs to agree on a schedule
627 13:28 < Callum> hmm. true i guess, by the time adrian gets the bill of materials, clears it and the stuff gets ordered in
628 13:28 < Callum> but at the current rate shit wont be chosen in time
629 13:29 < jtanx> i'm surprised that not much has been done in three weeks
630 13:29 < sam_moore> The problem is there are too many people working on this
631 13:29 < Callum> its been less than 3 weeks though
632 13:30 < sam_moore> Right. Let's make a schedule then.
633 13:30 < sam_moore> Just a second
634 13:30 < Callum> we only got the teams on like wed first week
635 13:30 < jtanx> ok
636 13:31 < Callum> And having 5-6 people per team across 6 teams without a project manager...makes sense
637 13:31 < sam_moore> Haha
638 13:31 < sam_moore> Ok, so I have an excel document
639 13:31 < sam_moore> Anyone here actually made a schedule for a project?
640 13:32 < jtanx> nope
641 13:32 < sam_moore> Welp
642 13:32 < jtanx> ms project was suggested in cits3200
643 13:32 < jtanx> nice gantt chart and everything
644 13:32 < sam_moore> Does it allow collaborative editing?
645 13:33 < sam_moore> Also, is there an open source version :P
646 13:33 < sam_moore> Ok, I've shared a google spreadsheet
647 13:34 < jtanx> not likely haha although there was something called ms project server which might allow collaboraitve stuff
648 13:34 < jtanx> you can get this all off msdnaa
649 13:34 < jtanx> but since noone's used it before it might be better to stick with excel
650 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
651 13:35 < Callum> HAHAH
652 13:35 < sam_moore> Well
653 13:35 < Callum> Hello everyone,
654 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.
655 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.
656 13:35 < Callum> PLEASE RETURN THE SHEETS.
657 13:35 < Callum> Thank you
658 13:35 < Callum> thats hilarious
659 13:35 < jtanx> ~~
660 13:36 < sam_moore> Oh dear
661 13:36 < sam_moore> It strikes me that something like a Makefile, except a bit more GUI, would be good for this
662 13:37 < jtanx> wait
663 13:37 < jtanx> you lost me there - what are you referring to
664 13:37 < Callum> ^
665 13:37 < sam_moore> To compile C projects that involve several files, you use something called "make"
666 13:37 < sam_moore> You write a Makefile for it
667 13:37 < jtanx> yah
668 13:38 < sam_moore> The Makefile has a list of targets and what they depend on
669 13:38 < sam_moore> And how to make them once their dependency exists
670 13:38 < jtanx> ok
671 13:38 < sam_moore> Then you run "make" and it reads the make file and magically compiles everything in the right order
672 13:38 < Callum> yea we get what make is
673 13:39 < sam_moore> Ok, I was referring to the list of tasks
674 13:39 < sam_moore> That depend on each other
675 13:39 < jtanx> ook
676 13:39 < jtanx> well
677 13:39 < sam_moore> It was a bad joke
678 13:39 < sam_moore> I am not seriously suggesting we use make to plan the project
679 13:40 < Callum> hahahah
680 13:40 < Callum> now that i would like to see :p
681 13:40 < jtanx> um just with git
682 13:40 < jtanx> i've never done pull requests before
683 13:40 < sam_moore> Neither had we until last week :P
684 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
685 13:42 < jtanx> ahh
686 13:42 < jtanx> ok
687 13:51 < jtanx> well that was pretty straight forward - I understand it now
688 15:06 < sam_moore> I made a #mctxuwa channel for group representatives
689 15:06 < sam_moore> I don't know if people will use it, but at least it's an attempt at something
690 15:47 < Callum> tbh it makes more sense for us all to use one
691 15:47 < Callum> unless the one for everyone is actually used often enough to justify us having our own
692 16:11 < sam_moore> Yeah, there's nothing stopping people that aren't group representatives from joining it
693 16:11 < sam_moore> It will certainly make it easier if there are more people talking to other teams directly than just the representative
694 16:11 < sam_moore> We might still want our own for discussing the details of code
695 16:12 < sam_moore> Speaking of which, I'm currently tidying up the test webserver code I wrote
696 16:17 < sam_moore> Does: FunctionName, variable_name, Structure, Extern_FunctionName, g_global_variable seem suitable
697 16:19 < sam_moore> Well, unless anyone objects before I've satisfied my obsessive compulsive urges, that's what it will be
698 16:19 < sam_moore> Until then, it'll probably take a while, and find-replace is fast
699 16:20 < sam_moore> Other than that, the style of comments/documentation in the test webserver is what I'll keep using
700 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
701 16:22 < sam_moore> Then we can put some kind of emergency "Turn all the things off!" in that
702 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
703 16:58 < sam_moore> Oh cool, that looks good
704 17:03 < sam_moore> I'll be back later tonight, bye
705 17:21 < jtanx> umm
706 17:21 < jtanx> wow okay you're actually writing a webserver from the ground up?
707 17:22 < jtanx> what if you just had software that got the results and then wrote that to a html/php file
708 17:22 < jtanx> then you can just run nginx and serve it up
709 17:45 < jtanx> or what about if you ran an sql server, so you update the database from your program
710 17:46 < jtanx> then you can either use php to interface with the database
711 17:46 < jtanx> or you could make some sort of api and serve the data in json format
712 17:50 < jtanx> sqlite
713 19:12 < jtanx> you could do something like this: http://pastebin.com/mEdbu4jR
714 19:13 < jtanx> where instead of outputting html, you could make it output json, which is then interpreted by your actual webpage
715 20:44 -!- Callum [[email protected]] has quit [Ping timeout]
716 20:49 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
717 20:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
718 22:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
719 --- Day changed Wed Aug 14 2013
720 07:58 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
721 09:13 < jtanx> I've done a version using fastcgi, which was surprisingly quite easy to set up
722 09:13 < jtanx> see here: https://github.com/jtanx/MCTX3420/tree/master/testing/fastcgi-approach
723 10:41 < sam_moore> That looks interesting, I'd prefer that to the PHP/database solution
724 10:42 < sam_moore> My concern is: You have to query the web server to start the process, even though it keeps running
725 10:42 < sam_moore> Also, I know "write a custom HTTP server" sounds scary, but it does actually work
726 10:43 < jtanx> nah
727 10:43 < jtanx> fastcgi
728 10:43 < jtanx> the process is started once and always runs
729 10:43 < jtanx> so you have a request loop
730 10:44 < jtanx> wait
731 10:44 < jtanx> how do you envision it working?
732 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
733 10:45 < jtanx> yeah
734 10:46 < jtanx> except that you don't have to worry about maintaining your own webserver
735 10:46 < sam_moore> Cool
736 10:46 < sam_moore> I do think that the HTTP server isn't that hard, and it's mostly working
737 10:46 < sam_moore> But we can probably switch to fastcgi
738 10:48 < sam_moore> I mean, we still have to parse a query string right?
739 10:48 < jtanx> well yes
740 10:48 < jtanx> if your request was
741 10:48 < jtanx> http://blah/cgi/?key=value&anotherkey=value2
742 10:48 < jtanx> you'd get back key=value&anotherkey=value2
743 10:48 < jtanx> as query string
744 10:50 < jtanx> try it out here: http://124.169.120.181:8080/cgi
745 10:51 < jtanx> (hopefully that forwards ok)
746 10:51 < sam_moore> Yep, that's cool
747 10:51 < sam_moore> The HTTP server I wrote basically does that
748 10:51 < sam_moore> But if it really bothers you, I'm fine with switching to fastcgi :P
749 10:52 < jtanx> well whatever works
750 10:52 < jtanx> but I thought it might be more maintainable if you used something that already exists :P
751 10:52 < sam_moore> Yeah, but thinking about it, what maintainence does the HTTP server require?
752 10:53 < sam_moore> Oh well, it's a good idea
753 10:53 < jtanx> for this situation not much
754 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
755 10:58 < sam_moore> Have you done multithreading in C before?
756 10:58 < jtanx> in windows yes
757 10:58 < jtanx> on linux not really
758 10:58 < sam_moore> Ah, I've only done it on linux
759 10:58 < jtanx> i did a bit in operating systems
760 10:59 < jtanx> but kinda forgot
761 10:59 < sam_moore> It shouldn't be too hard for our purposes
762 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
763 11:01 < jtanx> say they had some new fangled thing that requires php
764 11:01 < jtanx> which isn't going to work 
765 11:01 < jtanx> but with a standard webserver like apache or nginx, it's really easy to just install an extra addon
766 11:02 < sam_moore> I suppose... what would they need the new fangled php thing for?
767 11:03 < jtanx> well that's the thing - for now I don't know, but it could be required
768 11:03 < sam_moore> Yeah, good point
769 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
770 11:04 < sam_moore> For example, it would be a fair amount of work to add SSL to make the custom thing do https
771 11:04 < jtanx> oh yeah
772 11:04 < jtanx> that too
773 11:04 < sam_moore> Also we might want some authentication on it
774 11:04 < jtanx> nginx/apache are highly customisable
775 11:05 < sam_moore> I've never used nginx, what are it'
776 11:05 < sam_moore> s advantages over apache2?
777 11:05 < jtanx> nginx
778 11:05 < jtanx> yup
779 11:05 < jtanx> its really good
780 11:05 < sam_moore> Haha
781 11:05 < jtanx> a lot of sites use it because it's fast
782 11:05 < sam_moore> Fast is good
783 11:05 < jtanx> faster than apache
784 11:05 < sam_moore> Sold
785 11:05 < sam_moore> Well, we only need one user as well
786 11:05 < sam_moore> In fact, we deliberately do not want to have multiple clients able to use the thing at the same time
787 11:05 < jtanx> haha true
788 11:07 < sam_moore> Ok, so I think you've convinced me to use fastcgi
789 11:07 < sam_moore> Most of the custom HTTP server was reused code, so I didn't waste too much time on it
790 11:07 < jtanx> haha ok
791 11:07 < jtanx> have you written one before?
792 11:09 < sam_moore> Not specifically a HTTP server, but I've written a project for posix systems with a fair bit of networking
793 11:09 < sam_moore> git.ucc.asn.au/?p=matches/swarm.git
794 11:10 < jtanx> nice
795 11:10 < sam_moore> It allows you to run a shell, eg: bash accross multiple machines at once
796 11:11 < sam_moore> Not as useful as I thought it might be, but it was fun
797 11:12 < jtanx> heh
798 11:12 < jtanx> what did you end up using it for?
799 11:13 < sam_moore> I was setting up a programming competition where you have AIs play against each other
800 11:13 < sam_moore> I wanted to make a round robin
801 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
802 11:14 < jtanx> oO
803 11:14 < sam_moore> Well it turned out no one entered the competition, so I probably didn't need to go overboard
804 11:14 < sam_moore> But maybe I can use it for something else
805 11:15 < sam_moore> For the threading I'm thinking of using pthreads
806 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
807 11:16 < jtanx> okay
808 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
809 11:17 < jtanx> yeah that would be good
810 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
811 11:18 < sam_moore> We don't have the exact details of pretty much anything yet
812 11:18 < sam_moore> Maybe talk to James/Rowan about how the GUI is going to query the server
813 11:19 < sam_moore> Also, did you see my suggested naming convention?
814 11:19 < jtanx> no
815 11:20 < sam_moore> I don't really mind, although I'd prefer not to have hungarian notation
816 11:20 < sam_moore> As long as it'
817 11:20 < sam_moore> s consistent
818 11:21 < sam_moore> But the suggestion was: FunctionName, variable_name (local or member), Structure, ENUMVALUE, Extern_FunctionName, g_global
819 11:21 < jtanx> okay I'll try to keep to that
820 11:22 < sam_moore> Cool, I should probably go do something else
821 12:33 < jtanx> i gotta go
822 12:33 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
823 15:39 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
824 16:22 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
825 16:23 -!- justin_kruger [[email protected]] has quit [EOF From client]
826 16:43 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
827 16:56 < jtanx_> a beagleboard
828 16:56 < jtanx_> hmm
829 16:58 -!- jtanx [[email protected]] has quit [Ping timeout]
830 16:58 -!- jtanx_ is now known as jtanx
831 17:03 < jtanx> is it the beaglebone black?
832 17:03 < jtanx> sounds interesting
833 17:04 < sam_moore> They didn't specify
834 17:04 < sam_moore> Oh right, I accidentally cut out his message
835 17:04 < sam_moore> tl;dr "Beagle Board"
836 17:04 < jtanx> the beagle board is around $125 though
837 17:04 < sam_moore> Probably the Beaglebone black
838 17:04 < sam_moore> Oh really
839 17:04 < sam_moore> Heh
840 17:04 < jtanx> yeah
841 17:05 < jtanx> the beaglebone black is $45
842 17:05 < jtanx> but just looking the A/D converter on the black has a max voltage of 1.8v
843 17:05 < sam_moore> That's probably what they meant, since they said it is "not much more expensive"
844 17:05 < sam_moore> That should be fine; the sensors team says things are in mV
845 17:05 < jtanx> okay
846 17:05 < jtanx> that's good
847 17:05 < sam_moore> Really though... electronics should be asking the sensors team stuff like this
848 17:06 < jtanx> heh yeah
849 17:06 < sam_moore> They should probably have asked us if it was feasable for software
850 17:06 < sam_moore> Maybe they had someone who knew it would be, but still
851 17:06 < sam_moore> It looks like it is anyway, so crisis averted
852 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
853 17:07 < sam_moore> Yes, the sensors guy knows that
854 17:07 < jtanx> yeah so if its only 1.8v there's less range than 0-5v
855 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
856 17:10 < sam_moore> I think so; you get ~4x more resolution from the 12 bit ADC and lose ~3x from the lower range
857 17:10 < sam_moore> Also there's no set requirement yet on what the resolution should be
858 17:11 < jtanx> true
859 17:11 < jtanx> well in any case the bb black sounds quite nice
860 17:11 < sam_moore> Yep, it'll probably be good to use
861 17:14 < sam_moore> I'm much happier now that we actually have regular verbal communication with the other teams
862 18:23 < sam_moore> I'm looking into getting doxygen working for this
863 18:59 < jtanx> for the documentation?
864 18:59 < jtanx> seems good, but never used it before myself
865 19:01 < jtanx> looks a lot like javadoc
866 21:26 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
867 21:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
868 22:54 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
869 --- Day changed Thu Aug 15 2013
870 01:20 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
871 01:20 -!- justin_kruger [[email protected]] has quit [EOF From client]
872 07:58 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
873 08:21 < jtanx> hey
874 08:22 < jtanx> just a suggestion for the logging functions, but you can use macros
875 08:22 < jtanx> to get the function name (and even file name)
876 08:22 < jtanx> v
877 08:22 < jtanx> http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
878 08:23 < jtanx> so you can do stuff like #define Log(level, fmt, ...) LogReal(level, __func__, fmt, __VA_ARGS__)
879 08:25 < jtanx> it should be c99 conformant
880 09:15 < jtanx> I created a pull request anyway
881 09:33 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
882 13:33 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
883 13:39 < sam_moore> Yeah, I probably should have looked at that
884 13:46 < jtanx> back to the rpi+arduino
885 13:47 < jtanx> didn't they know about the beagle board black, or can that not be used for some reason?
886 13:48 < jtanx> beagle bone* black
887 14:20 < sam_moore> I don't know what model they were looking at exactly
888 14:20 < sam_moore> I told them the Beagle Bone was about $50, I haven't had much time to research it myself
889 14:20 < sam_moore> I didn't know about the Beagle Board/Bone, which was why I suggeste the RPi + Arduino
890 14:20 < sam_moore> They originally were just considering an Arduino
891 14:21 < sam_moore> Which would not have been fun for the remote interfacing stuff
892 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
893 14:22 < sam_moore> Also image processing would have been interesting
894 14:23 < sam_moore> Next time there's a combined groups meeting, hopefully we can talk to them more
895 14:24 < jtanx> yeah
896 14:24 < jtanx> there's quite a few
897 14:24 < jtanx> there's a beagleboard which is ~150
898 14:24 < jtanx> beaglebone which is ~90
899 14:24 < jtanx> beaglebone black which is ~50
900 14:24 < sam_moore> Right
901 14:24 < sam_moore> So they were probably looking at the beaglebone for $90
902 14:24 < jtanx> yeah probably
903 14:24 < jtanx> it's weird because the black version has better specs, from what i can see
904 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
905 14:25 < jtanx> yeah exactly
906 14:25 < sam_moore> Arduinos themselves cost a bit
907 14:25 < jtanx> well
908 14:25 < jtanx> you can get equivalents off ebay
909 14:25 < jtanx> like an uno is $10
910 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
911 14:26 < jtanx> yeah
912 14:26 < jtanx> well how many sensors are needed
913 14:26 < sam_moore> If it doesn't, you might have to add an Arduino or two anyway
914 14:26 < jtanx> you could just add on an adc chip
915 14:26 < sam_moore> Yes, or something like that
916 14:27 < jtanx> the beaglebone has like a bazillion gpio ports
917 14:31 < sam_moore> Well without getting into the specific details, it sounds like we should recommend they use that
918 14:32 < sam_moore> Apparently the sensors team will have a list ready by monday, which will be good
919 14:33 < jtanx> that'd be good
920 14:35 < jtanx> when are combined group meetings? just the 9am slot? 
921 14:36 < sam_moore> 9am Tuesday is the "official" time picked by Adrian, 2pm Wednesday is the time that we agreed between the teams
922 14:36 < sam_moore> I'm going to go to both, if more people want to come from the team that's also good
923 14:37 < sam_moore> Realistically not everyone is going to come, so I'll have to send emails a lot
924 14:38 < jtanx> ok
925 14:39 < sam_moore> What account do you need to be invited to the dropbox?
926 14:39 < sam_moore> I think Alex invited everyone using their student email
927 14:40 < sam_moore> Oh right, you wouldn't have been in the list that he used if you enrolled late
928 14:40 < jtanx> yeah, through student email would be good
929 14:41 < jtanx> last year's experiment ran with an arduino diecimila which only had 5 analogue inputs
930 14:41 < jtanx> any reason why we need more?
931 14:41 < jtanx> sorry that's 6
932 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
933 14:43 < jtanx> ok
934 14:44 < jtanx> At that rate you would definitely need something with more analogue inputs
935 14:45 < sam_moore> We also might need a DAC for one of the pneumatics team's devices
936 14:46 < sam_moore> But you can't get that on a microcontroller, there'd have to be a seperate module
937 14:46 < jtanx> yep
938 14:48 < jtanx> it'd be no point interfacing an arduino to the rpi/beaglebone if all you want is more analog inputs
939 14:49 < sam_moore> If you can get modules for ADC that can talk to a rpi/beaglebone, then yes
940 14:49 < jtanx> yeah
941 14:49 < jtanx> I don't think they're too hard to wire up
942 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
943 14:50 < sam_moore> Well not at length anyway
944 14:51 < sam_moore> Just when I happen to bump into Omid
945 14:51 < jtanx> hmm
946 14:54 < sam_moore> This project is probably going to be a good lesson in "Why you need a project manager"
947 14:55 < jtanx> so true
948 14:59 < jtanx> with the web interface, what sort of update times are we looking at?
949 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
950 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
951 15:01 < jtanx> yeah
952 15:07 < jtanx> I wonder what sort of performance impact running one (or two) cameras would have on the rpi/beaglebone
953 15:44 < jtanx> urgh
954 15:45 < jtanx> I was wondering why my nginx config wasn't working
955 15:45 < jtanx> until I realised that gedit was creating a backup copy of the config file
956 15:45 < jtanx> so nginx was reading both the original and backup
957 17:28 < sam_moore> That's wierd, you'd think it would only read one config file
958 17:34 < jtanx> well it was in a config directory
959 17:36 < sam_moore> Oh, ok
960 18:49 < jtanx> so the current idea i have with the web thing is
961 18:49 < jtanx> you can query it like http://domain/api/module?key=value&key=value2
962 18:50 < jtanx> and then you could return something in json format or whatever is most suitable for the ajax query
963 19:46 < jtanx> you can test it at http://mctx.us.to:8080/apoi
964 19:46 < jtanx> woops, http://mctx.us.to:8080/api
965 19:46 < jtanx> the only 'module' which will give a response of '200 OK' is sensors
966 19:47 < jtanx> which currently spits back any arguments you pass to it
967 19:47 < jtanx> eg http://mctx.us.to:8080/api/sensors?k=v
968 19:50 < jtanx> hopefully it doesn't break
969 20:44 < sam_moore> I'll take a look
970 20:45 < sam_moore> Looks good
971 20:45 < sam_moore> I'm writing a dummy thread for a sensor now
972 21:04 < jtanx> the code behind it (in the cgi module) is a bit clunky right now though
973 21:04 < jtanx> is there a meeting tomorrow?
974 21:05 < sam_moore> I don't think so, sorry
975 21:06 < jtanx> ok that's alright
976 21:06 < sam_moore> Things aren't urgent (yet)
977 21:07 < jtanx> heh
978 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
979 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
980 21:16 < jtanx> ok
981 21:17 < jtanx> i'll try to remember that
982 21:18 < jtanx> do you think we need to keep track of how long we spend on this project
983 21:18 < jtanx> for that 'cost estimate'
984 21:28 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
985 21:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
986 22:23 < sam_moore> For the cost estimate: Yes, we are supposed to have a technical diary (hand written)
987 22:23 < sam_moore> Including all notes and times worked on the project
988 22:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
989 --- Day changed Fri Aug 16 2013
990 08:00 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
991 09:48 < jtanx> I was wondering what sort of model you have for reading/storing sensor values and controlling actuators
992 10:02 < sam_moore> At the moment each sensor has a thread that continuously polls the sensor and dumps data to a binary file
993 10:03 < sam_moore> For reading there is a thread that fills a buffer from the file when it gets a request
994 10:04 < sam_moore> It might be better to change to a single thread for sensors/actuators though
995 10:04 < jtanx> yeah, I was about to say if it was necessary to have one for each
996 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
997 10:05 < jtanx> how do you wish to pass the data to the fcgi module?
998 10:06 < jtanx> right now
999 10:06 < jtanx> i've kinda set it so
1000 10:06 < jtanx> there's this thing called a ModuleHandler
1001 10:07 < jtanx> so you can pass it some data (tba what this is), and it also receives the query string from the use
1002 10:09 < sam_moore> Well, the ModuleHandler gets called whenever the right HTTP request is made right?
1003 10:10 < sam_moore> So, that function retrieves the data it needs to respond to the request
1004 10:10 < jtanx> well rightnow the typedef is
1005 10:10 < jtanx> typedef void (*ModuleHandler) (Data *data, char *params);
1006 10:10 < jtanx> so it's up to you to write a module handler (eg SensorsHandler)
1007 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?
1008 10:11 < jtanx> well the data thing was a placeholder for whatever sensors/actuators data there was
1009 10:11 < sam_moore> Is it meant to be sensor data, or is it a value that the user has passed through HTTP
1010 10:11 < jtanx> the query string is part of params
1011 10:11 < sam_moore> Ok, right, that makes more sense
1012 10:12 < sam_moore> My view had the ModuleHandler getting the appropriate data itself
1013 10:12 < jtanx> Ok
1014 10:12 < sam_moore> Given the params
1015 10:13 < jtanx> I'm just not really used to using global variables
1016 10:13 < sam_moore> The global sensors array?
1017 10:13 < jtanx> yeah
1018 10:13 < jtanx> i take it that's where you access data from?
1019 10:14 < sam_moore> Yes
1020 10:14 < jtanx> oh yeah one more thing, when you get a request, should it only return the latest data?
1021 10:20 < sam_moore> We should probably think some more about this as a whole group
1022 10:20 < sam_moore> So, you have a sensor that can (probably) poll a lot faster than you get requests via jQuery
1023 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
1024 10:22 < sam_moore> Or you can have it so that the sensor is continuously polling (What my code is simulating at the moment)
1025 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
1026 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)
1027 10:23 < jtanx> hmm
1028 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
1029 10:23 < jtanx> yeah
1030 10:24 < jtanx> I agree with you there
1031 10:24 < jtanx> so you're saying, continuously poll and log the results
1032 10:24 < jtanx> and when a request comes in, send back all the data up to the point when the last request came in
1033 10:25 < sam_moore> Well that's what the server program I wrote simulates at the moment.
1034 10:25 < sam_moore> However it might be more sensible for the request to just get the most recent data.
1035 10:25 < jtanx> hmm
1036 10:25 < sam_moore> Ah, yeah that's probably better actually
1037 10:25 < jtanx> then you're logging more points than youdisplay
1038 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.
1039 10:26 < sam_moore> In fact I think we'd want to do that.
1040 10:27 < jtanx> yeah ok
1041 10:27 < jtanx> that sounds not too bad
1042 10:27 < jtanx> but if that's the case
1043 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
1044 10:27 < jtanx> true
1045 10:27 < sam_moore> The GUI is for getting live information on the state of the system more than for data analysis
1046 10:27 < jtanx> but if that's the case you might want to allow direct access to the latest dataset
1047 10:28 < jtanx> instead of having to read from the file
1048 10:28 < jtanx> if that's possible
1049 10:28 < jtanx> then you can directly record the results in csv format
1050 10:28 < sam_moore> Yes, I thought about that; you can have a buffer of points accessed by the request thread easily enough
1051 10:29 < sam_moore> There are some difficulties though with managing the buffer
1052 10:30 < sam_moore> Wait, maybe it's easier than I though
1053 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
1054 10:32 < sam_moore> I have some other stuff to do today unfortunately
1055 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
1056 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
1057 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
1058 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
1059 10:36 < jtanx> ok, I'll keep that in mind
1060 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
1061 11:13 < jtanx> well it might not only be sensor data
1062 11:13 < jtanx> it could be actuator stuff or anything else
1063 11:13 < sam_moore> I suppose
1064 11:14 < jtanx> maybe I should change the typedef to void*
1065 11:14 < jtanx> then you can cast it to whatever
1066 11:14 < sam_moore> Yeah, that will work
1067 11:15 < sam_moore> Actuator stuff is going to be a bit of a seperate (hopefully easier) problem
1068 11:15 < sam_moore> In that case you can just wait for a query before doing anything
1069 11:15 < sam_moore> Anyway, I've distracted myself again, this is just too interesting :S
1070 11:15 < jtanx> hahaha
1071 11:16 < jtanx> anycase for the actuator you would have a separate handler function
1072 11:16 < sam_moore> Yes
1073 11:16 < jtanx> eg ActuatorHandler
1074 11:20 < jtanx> fcgi is pretty whack
1075 11:20 < jtanx> it replaces printf
1076 11:21 < jtanx> so when you printf (or fwrite for binary?), that gets sent to the client
1077 12:03 < jtanx> hey
1078 12:04 < jtanx> what if we stored stuff in an sqlite library
1079 12:04 < jtanx> sorry database
1080 12:04 < jtanx> on second thoughts nah
1081 14:58 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1082 15:01 -!- jtanx [[email protected]] has quit [Ping timeout]
1083 15:02 -!- jtanx_ is now known as jtanx
1084 15:11 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1085 15:18 -!- jtanx [[email protected]] has quit [Ping timeout]
1086 18:59 -!- jtanx_ is now known as jtanx
1087 21:28 < sam_moore> So, I did a bit of testing with sqlite vs a binary file
1088 21:28 < sam_moore> sqlite takes about 1000x as long for saving data
1089 21:28 < sam_moore> I haven't tested reading it back yet
1090 21:28 < sam_moore> But more worrying
1091 21:28 < sam_moore> I get a segmentation fault using sqlite
1092 21:29 < sam_moore> And it's in the sqlite library somewhere; not my test code
1093 21:29 < sam_moore> Running sqlite in valgrind shows a bunch of complaints about uninitialised values
1094 21:29 < sam_moore> So... I'd recommend we just use a binary file
1095 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
1096 21:36 < jtanx> yeah sqlite not so good for file performance
1097 21:36 < jtanx> because every insert it has to confirm the write to disk
1098 21:36 < jtanx> the segfault
1099 21:36 < jtanx> may actually be because you didn't initialse the mutex
1100 21:36 < jtanx> es
1101 21:36 < jtanx> i tried compiling it on mingw and it segfaults on the mutex unlock
1102 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
1103 21:37 < jtanx> nah 
1104 21:38 < jtanx> fcgi_stdio just has a bunch of defines
1105 21:38 < sam_moore> Oh really, that's wierd
1106 21:38 < jtanx> so printf becomes FCGI_printf
1107 21:38 < jtanx> so fcgi_stdio must be the first include in the fcgi module
1108 21:38 < sam_moore> I would have thought it was simpler to just change stdout than replace the whole printf function
1109 21:38 < sam_moore> But whatever, we're not implementing fcgi :P
1110 21:38 < jtanx> haha
1111 21:39 < sam_moore> Oh, the mutex needs initialising, yeah
1112 21:39 < sam_moore> But the test I did was just a serial program, no mutex
1113 21:39 < jtanx> ah
1114 21:39 < jtanx> well
1115 21:39 < sam_moore> We'll be using gcc to compile on the beaglebone/rpi
1116 21:40 < sam_moore> I think some implementations of pthreads need an initialiser but others don't, I'll have to check
1117 21:40 < sam_moore> But pthread_mutex_init doesn't show up in man pages on debian
1118 21:40 < jtanx> yeah it's not on ubuntu either
1119 21:41 < jtanx> have you ever worked with clang
1120 21:42 < sam_moore> No
1121 21:42 < jtanx> neither but it seems pretty cool
1122 21:45 < jtanx> when you compile it gives better diagnostic output when something goes wrong
1123 21:46 < jtanx> it's a drop in replacement for gcc
1124 21:47 < sam_moore> Interesting
1125 21:51 -!- jtanx [[email protected]] has quit ["brb"]
1126 21:55 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1127 21:57 < jtanx> if you kept the file handles for the sensor data always open
1128 21:58 < jtanx> and immediately wrote to them when a data point is polled 
1129 21:58 < jtanx> is there much performance difference to buffering first?
1130 22:05 < sam_moore> Yeah, it's probably better to keep the file handles always open
1131 22:05 < sam_moore> The operating system will use some kind of buffer for the file anyway
1132 22:06 < sam_moore> I've got some basic programs, maybe I'll make some performance graphs tomorrow
1133 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
1134 22:08 < sam_moore> I should look into a #define or something to initialise the mutexes if they need to be
1135 22:09 < sam_moore> Anyway, I need to sleep
1136 22:11 < sam_moore> I wonder how James and Callum are going, they haven't been in the channel for a while
1137 22:12 < jtanx> yeah, it's pretty quiet
1138 22:17 < sam_moore> If we can get a second meeting in the week, preferably a longer one that would be good
1139 22:18 < sam_moore> Particularly if we can start working on code at the same time
1140 22:18 < sam_moore> But we'll see
1141 22:18 < sam_moore> Everyone has other stuff to do after all
1142 22:18 < sam_moore> I'm spending way too much time on this unit compared to my others
1143 22:18 < sam_moore> Then again this unit will probably require the most work
1144 22:19 < sam_moore> Anyway, bye
1145 22:23 < jtanx> bye
1146 22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
1147 --- Day changed Sat Aug 17 2013
1148 10:29 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1149 17:14 -!- justin_kruger [[email protected]] has joined #mctxuwa_softdev
1150 17:14 -!- justin_kruger [[email protected]] has quit [EOF From client]
1151 22:25 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
1152 --- Day changed Sun Aug 18 2013
1153 08:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1154 11:44 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1155 11:45 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1156 12:00 -!- jtanx [[email protected]] has quit [Ping timeout]
1157 12:03 -!- jtanx_ [[email protected]] has quit [Ping timeout]
1158 12:04 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1159 21:53 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1160 22:37 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
1161 --- Day changed Mon Aug 19 2013
1162 08:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1163 11:43 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1164 12:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1165 13:34 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1166 17:42 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1167 20:07 < jtanx> just so you know, I'm changing the JSON functions
1168 21:04 < sam_moore> Ok, I already pushed some stuff to github
1169 21:05 < sam_moore> But we can get it to merge
1170 21:05 < sam_moore> I ended up just using printf to make part of the JSON in the SensorHandler anyway
1171 21:06 < jtanx> depending on where SensorHandler is
1172 21:06 < jtanx> that may or may not work
1173 21:06 < jtanx> inside of fastcgi.c it willwork
1174 21:06 < jtanx> outside it won't
1175 21:07 < jtanx> oh ok
1176 21:07 < jtanx> I see
1177 21:07 < jtanx> so that's fine
1178 21:08 < jtanx> it might be best not to use a do while loop 
1179 21:08 < jtanx> because if no arguments are passed
1180 21:08 < sam_moore> Ah, right
1181 21:08 < jtanx> then the keypair function will return null
1182 21:09 < jtanx> while ((params = FCGI_KeyPair(params, &key, &value)))
1183 21:09 < jtanx> will work fine
1184 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
1185 21:10 < jtanx> what was your input string?
1186 21:11 < sam_moore> "http://localhost/api/sensors?id=0"
1187 21:11 < jtanx> looks fine from this end
1188 21:11 < jtanx> http://mctx.us.to:8080/api/sensors?id=0
1189 21:11 < jtanx> it might be because of your do while loop
1190 21:12 < jtanx> yeah it will be because of that
1191 21:12 < sam_moore> The do while loop causes problems when there is an empty string
1192 21:13 < sam_moore> ie: No parameters are passed
1193 21:13 < jtanx> ok let's just put it this way; FCGI_KeyPair was designed to use a while loop
1194 21:13 < sam_moore> Ok, sure
1195 21:13 < sam_moore> I had some problems with just a while loop, but I'll try again
1196 21:13 < jtanx> yeah about that JSON stuff
1197 21:13 < jtanx> I'm still trying to think of a good way to do that
1198 21:13 < jtanx> especially with the array stuff
1199 21:19 < sam_moore> I'm not sure what I did before, but a while loop seems ok now
1200 21:19 < jtanx> heh
1201 21:21 < sam_moore> Ok, I have to go now
1202 21:21 < sam_moore> I might not be able to do much tomorrow, we'll see
1203 21:22 < jtanx> ok yep
1204 21:35 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1205 21:55 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1206 22:15 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1207 22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1208 23:08 -!- Callum [[email protected]] has quit [EOF From client]
1209 23:11 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1210 23:14 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1211 23:17 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1212 23:35 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1213 --- Day changed Tue Aug 20 2013
1214 07:44 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1215 08:11 -!- jtanx [[email protected]] has quit [Ping timeout]
1216 09:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1217 10:11 -!- jtanx [[email protected]] has quit [Ping timeout]
1218 10:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1219 13:11 -!- jtanx [[email protected]] has quit [Ping timeout]
1220 14:28 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1221 15:06 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1222 15:06 < Callum> hey same
1223 15:06 < Callum> sam*
1224 15:20 < jtanx> :>
1225 15:22 < Callum> he literally set himself to away as soon as i said that
1226 15:45 < jtanx> urgh this json stuff is doing my head in
1227 15:57 < sam_moore> Callum: I've been set to away since last night
1228 15:57 < Callum> o.O not according to my client
1229 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
1230 15:58 < Callum> ...why would they have to program it? wtf did they think we were doing?
1231 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.
1232 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)
1233 16:00 < sam_moore> Woah, I don't remember the assignments in that much detail
1234 16:00 < Callum> was hoping you would :p
1235 16:00 < sam_moore> No, I just have vague memories of algebra
1236 16:01 < sam_moore> And looking through notes
1237 16:01 < Callum> hmm. i cant seem to find anything in the notes
1238 16:01 < Callum> because he says to assume the rest mass of the anti-neutrino is 0
1239 16:02 < Callum> and i don't really remember much in regards to energies and 0 rest mass ;/
1240 16:02 < jtanx> I talked to someone who did computer vision before
1241 16:02 < jtanx> and he's really doubtful that you can get accurate readings off a webcam
1242 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
1243 16:02 < Callum> the question also says to have it in terms of m(pi) m(e) and c
1244 16:03 < Callum> and yea thats what i thought. it doesnt make sense to do that. just cant remember how to do it D;
1245 16:03 < Callum> @jeremy yea well, its a pain but possible
1246 16:04 < Callum> really comes down to how good your camera is/sampling rate/how quickly you can process it. 
1247 16:04 < sam_moore> How about you do some experimenting with a webcam and see what you can do with it?
1248 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)
1249 16:04 < jtanx> personally, I don't think it will work
1250 16:04 < sam_moore> It looks like we might just end up streaming images diretly to a website
1251 16:04 < Callum> i don't have any
1252 16:04 < Callum> yea well even if thats all we do we still need the camera
1253 16:05 < Callum> spose i could use my laptop one but i doubt that would be very good
1254 16:05 < Callum> could run it through the canny algorithm and see what it produces
1255 16:06 < sam_moore> Sounds like an idea
1256 16:07 < sam_moore> A good idea specifically
1257 16:07 < jtanx> about the sensorhandler
1258 16:07 < sam_moore> Yes?
1259 16:07 < jtanx> do you envision leaving it in fastcgi.c permanently
1260 16:07 < jtanx> or for that matter any other handlers
1261 16:07 < sam_moore> I was kind of thinking there would be a "handlers.h" and "handlers.c"
1262 16:08 < sam_moore> Just to make things more organised
1263 16:08 < jtanx> yeah
1264 16:08 < jtanx> I'm trying to export enough of the functionality
1265 16:08 < jtanx> to do that
1266 16:08 < jtanx> but the json thing is annoying
1267 16:08 < jtanx> especially when you need to spit out arrays
1268 16:09 < jtanx> unless you have something like FCGI_Printf
1269 16:09 < jtanx> and it's up to you to format it correctly
1270 16:09 < Callum> bloody physics lecture video is laggy. gonna have to download it and hope for the best. fuck echo
1271 16:10 < jtanx> compared to lectopia you get 2x filesize with no visible benefit in quality
1272 16:10 < Callum> they're both shit.
1273 16:10 < sam_moore> You could have seperate "BuildJSON_Key" and "BuildJSON_Value" functions, with a "BuildJSON_ValueArray" maybe
1274 16:10 < Callum> haha
1275 16:11 < sam_moore> FCGI_Printf is Ok though, it's not too much formating
1276 16:11 < jtanx> the problem with the buildjson_* stuff
1277 16:11 < jtanx> is it gets very verbose
1278 16:12 < jtanx> and you can probably come up witha  situation that breaks it too
1279 16:12 < jtanx> and don't get me started on value types
1280 16:12 < sam_moore> Haha
1281 16:14 < sam_moore> We can always just send plain text and make James turn it into JSON :P
1282 16:14 < jtanx> ahaha
1283 16:14 < jtanx> yeah that could work
1284 16:15 < jtanx> mm 
1285 16:15 < jtanx> this is where java is good
1286 16:15 < jtanx> or any other higher level language
1287 16:21 < jtanx> ok so it's a bit of both, but how about: FCGI_JSONKey(key) and FCGI_JSONValue(format, ...)
1288 16:22 < sam_moore> That looks good
1289 16:25 < jtanx> I'm also adding long/double types for the BuildJSON function, just for convenience
1290 16:25 < jtanx> any preference to naming conventions?
1291 16:26 < jtanx>  FCGI_BuildJSONLong
1292 16:27 < sam_moore> Seems OK
1293 16:28 < sam_moore> I need to go do some ENSC1001 stuff (hooray)
1294 16:29 < jtanx> yuck
1295 16:30 < Callum> hhaha
1296 16:30 < Callum> have fun :p
1297 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
1298 16:38 < Callum> well iv got an answer for the first part (second part should be the same process). just hope its right :s
1299 16:46 < jtanx> ok, time to merge this into the server code
1300 19:47 < jtanx> hmm interesting - it crashes if compiled with clang but not with gcc
1301 19:49 < jtanx> probably just a bug in clang 3.2
1302 20:08 < jtanx> ok, just submitted a pull request to update the fastcgi stuff
1303 20:08 < jtanx> for now I moved Sensor_Handler to sensor.c
1304 20:09 < jtanx> the status codes have all changed
1305 20:09 < jtanx> If you absolutely cannot process anything given the input arguments, you call FCGI_RejectJSON
1306 20:10 < jtanx> If you fail for some other reason (e.g unauthorized access), you use FCGI_BeginJSON with the appropriate status code
1307 20:10 < jtanx> With RejectJSON, it sends a HTTP 400 code so any query through AJAX/jQuery will fail with no extra info
1308 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
1309 20:12 < jtanx> BeginJSON will automatically add the module handler name + the status code
1310 21:47 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1311 --- Day changed Wed Aug 21 2013
1312 00:53 -!- Callum [[email protected]] has quit [EOF From client]
1313 07:45 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1314 11:57 < jtanx> hmm
1315 11:57 < jtanx> I just had a play with the sensor stuff
1316 11:57 < jtanx> and I trialled a 'double buffer' scheme
1317 11:57 < jtanx> instead of the binary file idea
1318 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
1319 12:35 < jtanx> urgh
1320 12:35 < jtanx> just worked through some stupid bug
1321 12:37 < jtanx> I think it's because make didn't recompile something because it thought it hadn't changed
1322 12:38 < jtanx> probably the header files
1323 12:50 < jtanx> you can see the double buffer method in this branch: https://github.com/jtanx/MCTX3420/tree/doublebuffer
1324 12:58 < jtanx> one issue though is that writing out csv instead of binary file takes up a lot more space
1325 14:49 -!- james__ [[email protected]] has joined #mctxuwa_softdev
1326 14:49 < james__> Hey
1327 14:50 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1328 18:32 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1329 19:48 -!- jtanx [[email protected]] has quit [Ping timeout]
1330 19:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1331 23:12 -!- jtanx [[email protected]] has quit ["・_・"]
1332 --- Day changed Thu Aug 22 2013
1333 00:46 -!- Callum [[email protected]] has quit [EOF From client]
1334 08:19 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1335 10:00 -!- jtanx [[email protected]] has left #mctxuwa_softdev []
1336 13:19 -!- callum [[email protected]] has joined #mctxuwa_softdev
1337 13:20 < callum> hey
1338 13:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1339 14:35 -!- callum [[email protected]] has quit [Ping timeout]
1340 15:07 -!- callum [[email protected]] has joined #mctxuwa_softdev
1341 15:07 < callum> sam you still at uni?
1342 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.
1343 15:34 < jtanx> um
1344 15:34 < jtanx> I can't remember
1345 15:34 < jtanx> didn't you use pkg config to find out
1346 15:36 < jtanx> try this http://opencv.willowgarage.com/wiki/CompileOpenCVUsingLinux
1347 15:54 -!- callum [[email protected]] has quit [EOF From client]
1348 21:43 -!- jtanx [[email protected]] has quit ["._."]
1349 22:08 < sam_moore> gcc -o opencv opencv.c -I/usr/include/opencv -lopencv_core -lopencv_highgui -lopencv_imgproc
1350 22:08 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
1351 22:08 < sam_moore> Oh... there's no one here
1352 22:08 < sam_moore> Well, if you read the IRC logs when they're commited to git, you'll see it. Good luck.
1353 --- Day changed Fri Aug 23 2013
1354 07:42 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1355 07:49 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1356 07:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1357 08:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1358 10:02 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1359 10:12 -!- jtanx [[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
1360 10:13 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1361 12:30 < jtanx_> um
1362 12:30 < jtanx_> do you know how you connected the relay board to the sensor board
1363 12:30 < jtanx_> for the soldering lab
1364 12:45 < jtanx_> and what sort of wire did you use?
1365 12:58 < jtanx_>  brb
1366 12:58 -!- jtanx_ [[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
1367 13:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1368 --- Log opened Sat Aug 24 17:07:53 2013
1369 17:07 -!- matches [[email protected]] has joined #mctxuwa_softdev
1370 17:07 -!- ServerMode/#mctxuwa_softdev [+nt] by irc.eversible.com
1371 17:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
1372 17:07 -!- Irssi: Join to #mctxuwa_softdev was synced in 1 secs
1373 17:08 -!- You're now known as sam_moore
1374 --- Day changed Mon Aug 26 2013
1375 11:11 -!- matches [[email protected]] has joined #mctxuwa_softdev
1376 11:11 -!- matches [[email protected]] has left #mctxuwa_softdev []
1377 11:12 <@sam_moore> Thought I might have the wrong server
1378 17:18 <@sam_moore> I do have the wrong server!
1379 17:19 -!- sam_moore [[email protected]] has left #mctxuwa_softdev [I have the wrong server!]
1380 --- Log closed Mon Aug 26 17:19:05 2013
1381 --- Log opened Mon Aug 26 17:19:34 2013
1382 17:19 -!- sam_moore [[email protected]] has joined #mctxuwa_softdev
1383 17:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
1384 17:19 -!- Irssi: Join to #mctxuwa_softdev was synced in 5 secs
1385 17:19 < sam_moore> !motd
1386 17:20 < sam_moore> '!motd'
1387 17:20 < sam_moore> MctxBot: You're broken
1388 17:20 < sam_moore> Oh wait, never mind
1389 18:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1390 18:08 < jtanx> :P
1391 18:09 < jtanx> you can change the message if you want
1392 21:03 -!- jtanx [[email protected]] has quit ["brb"]
1393 21:12 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1394 22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1395 --- Day changed Tue Aug 27 2013
1396 07:40 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1397 07:54 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1398 17:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1399 19:11 < jtanx> lol
1400 19:11 < jtanx> the camera that we were using for the soldering lab inserted a bunch of wavy lines/static into the video
1401 19:12 < sam_moore> It's an effect
1402 19:14 < jtanx> nah
1403 19:14 < jtanx> the camera was actually broken
1404 19:15 < sam_moore> (I figured that)
1405 19:15 < sam_moore> You could pretend it's supposed to be an 80s style video?
1406 19:15 < jtanx> yeah that could work
1407 19:16 < jtanx> have you done it yet?
1408 19:18 < sam_moore> No :S
1409 19:20 < jtanx> well
1410 19:21 < jtanx> according to the manual, you need to connect a wire from R5 on the sensor board to the relay board
1411 19:21 < jtanx> problem was we already chopped off the lead on R5
1412 19:22 < jtanx> another group connected the wire to the LEd though
1413 19:22 < jtanx> seemed to work
1414 20:02 < jtanx> so are we using clock_gettime?
1415 20:08 < sam_moore> I think so, we can use CLOCK_MONOTONIC_RAW if we are paranoid about the system time getting changed
1416 20:08 < sam_moore> Or we can just use CLOCK_REALTIME if we aren't
1417 20:09 < jtanx> I thought CLOCK_MONOTONIC was supposed to be best, because the RAW version wasn't compensated for temp/other stuff
1418 20:10 < jtanx> http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic
1419 20:10 < jtanx> about the FCGI loop blocking
1420 20:10 < jtanx> you can switch to FCGX_ methods
1421 20:10 < jtanx> I think
1422 20:11 < jtanx> but is it really necessary
1423 20:20 < jtanx> about the valgrind comment in sensors.c
1424 20:20 < jtanx> this is probably it: http://stackoverflow.com/questions/5844242/valgrind-yells-about-an-uninitialised-bytes
1425 20:23 < sam_moore> It's probably not necessary to stop the FCGI loop blocking, don't worry about it
1426 20:25 < sam_moore> Yeah, I didn't initialise the buffers anywhere
1427 20:25 < jtanx> actually I can't reproduce that message
1428 20:25 < sam_moore> Hmm
1429 20:26 < jtanx> about the sensor times
1430 20:27 < jtanx> what about if you all reference it relative to some point
1431 20:27 < jtanx> eg
1432 20:27 < sam_moore> The epoch :P
1433 20:27 < jtanx> lol
1434 20:27 < jtanx> I mean
1435 20:28 < jtanx> when you get sensor data, you store the difference in time between the start of recording and now
1436 20:28 < sam_moore> Sure, that makes more sense
1437 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
1438 20:30 < jtanx> yeah
1439 20:30 < jtanx> you could have a specific request to return the starting time
1440 20:30 < jtanx> then it's implicit for all requests
1441 20:30 < jtanx> btw I submitted a pull request for the nginx configs
1442 20:32 < sam_moore> Ok
1443 20:32 < sam_moore> I've added you to collaborators so you can merge them yourself if you need to
1444 20:33 < jtanx> ok
1445 20:35 < jtanx> huh
1446 20:35 < jtanx> http://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
1447 20:41 < sam_moore> Nice
1448 20:42 < sam_moore> "Currently you can not access Ethernet" Not so nice
1449 20:42 < sam_moore> Although this is dated 2011
1450 21:18 -!- jtanx [[email protected]] has quit ["bye"]
1451 --- Day changed Wed Aug 28 2013
1452 08:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1453 10:08 -!- MctxBot [[email protected]] has quit [Connection reset by peer]
1454 10:11 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
1455 10:39 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1456 15:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1457 15:48 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1458 16:31 < jtanx> huh
1459 16:31 < jtanx> firefox's javascript debugger is pretty cool
1460 16:31 < sam_moore> Firebug? Yeah
1461 16:35 < jtanx> nah the inbuilt one
1462 16:35 < jtanx> firebug's good for inspecting html though
1463 16:35 < jtanx> haven't used firebugs js debugger yet
1464 16:35 < sam_moore> Oh, I didn't know they had an inbuilt one
1465 16:36 < jtanx> Ctrl+Shift+K
1466 16:36 < sam_moore> Of course I normally use Iceweasel, which is currently built as firefox 10.0.2 with a different name
1467 16:36 < jtanx> well that's about 10 releases behind
1468 16:36 < sam_moore> That looks pretty similar to firebug anyway
1469 16:55 < jtanx> inline conditionals in javascript are whack
1470 16:55 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
1471 16:55 < sam_moore> I haven't done much javascript, but a lot of it does seem whack
1472 16:56 < sam_moore> jtanx: What are you working on in JavaScript?
1473 16:56 < jtanx> unit tests
1474 16:57 < sam_moore> Cool
1475 17:01 -!- Callum [[email protected]] has quit [Ping timeout]
1476 17:01 -!- Callum_ is now known as Callum
1477 17:18 < jtanx> javascript in general is annoying me though
1478 17:25 < Callum> when exactly is this soldering lab due? fucking thing.
1479 17:27 < jtanx> next friday
1480 17:27 < Callum> it says week 5 on lms
1481 17:27 < jtanx> sept 6
1482 17:27 < Callum> where's it say this?
1483 17:27 < jtanx> yeah he made an announcement
1484 17:27 < jtanx> that it's wrong
1485 17:27 < jtanx> somewhere
1486 17:28 < Callum> sigh. this unit..i swear
1487 17:28 < Callum> if it really is next week then i'd be so relieved
1488 17:28 < Callum> wow
1489 17:28 < Callum> he made an announcement today..
1490 17:28 < Callum> wait yesterday
1491 17:29 < jtanx> still got that central plant fbd to do
1492 17:29 < Callum> why hasnt LMS emailed me a notification? (/end spam)
1493 17:29 < Callum> yea i know
1494 17:29 < Callum> which i think i have it pretty much done
1495 17:29 < Callum> not 100% sure on it though
1496 17:29 < Callum> and whether to add pumps and shit into it
1497 17:29 < jtanx> what did you have on it?
1498 17:30 < Callum> HA as i say that i check my phone and i have the message about the announcement
1499 17:30 < jtanx> and what did you call the chiller things?
1500 17:30 < Callum> pretty much just the 4 chillers, a line showing it can go back (they're literally called chillers ahha(
1501 17:31 < Callum> then i had another part to show the chillers (evaporation/condensor/compressor and cooling tower is connected to condenser) 
1502 17:31 < jtanx> ook
1503 17:31 < Callum> however
1504 17:32 < Callum> im not sure about the input/output of the chiller
1505 17:32 < Callum> because stuff online shows it to be the evaporator 
1506 17:32 < Callum> but isnt it water being pumped?
1507 17:32 < jtanx> I think there were pumps on the output
1508 17:33 < jtanx> were there three outputs?
1509 17:33 < Callum> also not sure if i should/wherte to add the tank (yea ofc theres pumps but not sure to put them in to the diagram, pretty much everything is pumped)
1510 17:33 < Callum> outputs where?
1511 17:33 < jtanx> North/Sout/East distribution things
1512 17:33 < jtanx> iirc
1513 17:33 < jtanx> yeah not sure whether to add tank or not
1514 17:34 < Callum> oh that, i didnt bother with that
1515 17:34 < Callum> just how did the chiller connect with the rest of the plant?
1516 17:34 < Callum> was the evaporator the input/output?
1517 17:34 < Callum> because the chiller feeds out to the water tower and the tower feeds back into the chiller (i think)
1518 17:36 < Callum> also what was the thing called? that allowed water to flow back and forth bypassing the chillers. back something?
1519 17:36 < Callum> really they should have told us before we went in we had to do this. some lazy fucks like me dont read the outline so i didnt take notes..or try to commit stuff to memory :po
1520 17:39 < jtanx> the bypass?
1521 17:39 < jtanx> I haven't gone into detail
1522 17:39 < jtanx> so I just have chiller
1523 17:39 < jtanx> and cooling tower
1524 17:39 < jtanx> maybe I should
1525 17:40 < Callum> remember how tehre was 4 chillers, and they would only run what was needed.
1526 17:40 < jtanx> yeah
1527 17:40 < jtanx> how many cooling towers?
1528 17:40 < Callum> and if they had more than they needed there was a pipe to flow back, or if they had some chilled water from the tanks or w.e it bypassed chillers
1529 17:40 < Callum> i dont know, but im not sure how to show it all
1530 17:40 < Callum> im sure what iv got is somewhat decent
1531 17:41 < jtanx> I used visio and I ended up spending so much time trying to get the lines rihgt
1532 17:41 < jtanx> probably would have been faster to hand draw it
1533 17:41 < jtanx> still not finished too
1534 17:41 < Callum> haha im fiarly sure i read somewhere it was hand drawn :p
1535 17:41 < jtanx> meh I suck at drawing
1536 17:42 < Callum> maybe not. "This is to be drawn and annotated on single A4 page"
1537 17:42 < Callum> i dont think they'll be picky
1538 17:42 < jtanx> and there's lines everywhere
1539 17:42 < Callum> really? how do you have lines everywhere?
1540 17:42 < jtanx> ok so chiller
1541 17:42 < Callum> it's a fairly simple system. unless i'v done it wrong :s
1542 17:43 < jtanx> has warm chilled water (1), chilled coolant (2), hot coolant (3), chilled chilled water(4), control line (5), (maybe) sensor back to controller (6)
1543 17:43 < jtanx> that's ~5 lines in/out of one box?
1544 17:44 < Callum> hmm. havent included coolant or control/sensor
1545 17:44 < Callum> maybe i should :S
1546 17:44 < jtanx> and an operator
1547 17:44 < jtanx> to the controller
1548 17:45 < Callum> thing is it asked for a high level FBD though
1549 17:45 < Callum> which means not very detailed
1550 17:45 < Callum> or maybe it didnt?
1551 17:45 < jtanx> yeah, so do you need to show condensor/evaporator
1552 17:45 < jtanx> I just have a chiller box
1553 17:46 < jtanx> anyway... afk ~10 mins
1554 17:46 < Callum> the condensor/evaporater is part of the chiller isnt it?
1555 17:46 < Callum> ok
1556 18:10 < Callum> anyone finished reading chapter 4 of the notes?
1557 18:11 < jtanx> what's that
1558 18:11 < Callum> sensors
1559 18:12 < Callum> so dull :l
1560 18:12 < Callum> and pretty much no chance to remember enough of it. quiz tomorrow is going to be fun.. 
1561 18:12 < jtanx> oh 
1562 18:13 < jtanx> shit
1563 18:13 < jtanx> have to study for that
1564 18:13 < Callum> rofl
1565 18:14 < jtanx> :/
1566 18:15 < Callum> gonna just have to wing most of them again like last time most likely. 
1567 18:15 < jtanx> probably
1568 18:15 < jtanx> Well, the unit testing thing works http://mctx.us.to:8080/unit-tests/
1569 18:15 < jtanx> now what unit tests should there be
1570 18:18 < Callum> not sure.
1571 18:25 < Callum> brilliant! the notes show a false colour image built from a black and white image...while printed in black and white.
1572 18:34 < jtanx> :P
1573 19:50 < jtanx> um
1574 19:50 < jtanx> did we get around to doing the sparkplus thing
1575 19:54 < jtanx> we need to do it before the end of the week
1576 19:54 < Callum> umm.
1577 19:54 < Callum> actually justin already set up the group
1578 19:54 < Callum> so you need to hurry up and join before we have to recreate the group :P
1579 19:54 < jtanx> nah it expired
1580 19:54 < Callum> wait already?
1581 19:54 < Callum> zzz
1582 19:55 < jtanx> 5 hr deadline
1583 19:55 < Callum> and adrian said it was 24Hr, whats with this 5 hour shit
1584 19:55 < jtanx> so... we need to try again
1585 19:55 < jtanx> when everyone's available
1586 20:11 -!- Callum [[email protected]] has quit [Ping timeout]
1587 20:49 -!- jtanx [[email protected]] has quit ["ha"]
1588 --- Day changed Thu Aug 29 2013
1589 07:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1590 09:16 < jtanx> firefox blocks ajax calls if you try to run the file locally :/
1591 09:45 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1592 13:33 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1593 14:24 -!- james__ [[email protected]] has joined #mctxuwa_softdev
1594 14:25 < james__> Hey Jeremy. Is there a way to find my login hash key if i am already logged into the api?
1595 14:28 < jtanx> um
1596 14:28 < jtanx> right now you should store it
1597 14:29 < jtanx> just declare a global variable and set it to the hash
1598 14:30 < jtanx> or if you have made a class
1599 14:30 < jtanx> just make it an element
1600 14:31 < james__> I'm still logged in from ages ago and i can't logout so i can get a different key that works
1601 14:31 < jtanx> that
1602 14:31 < jtanx> ok
1603 14:31 < james__> Possibly a bug that needs fixing? 
1604 14:31 < jtanx> so the way it works right now is there's a 3 minute timeout on the key
1605 14:31 < jtanx> no
1606 14:31 < jtanx> there's actually two layers
1607 14:32 < jtanx> the password that you enter first (mctxadmin) is what's called HTTP basic authentication
1608 14:32 < jtanx> this lets you gain access to /api/login
1609 14:32 < james__> Well i tried loging in again and its saying i am already logged in
1610 14:32 < jtanx> when you reach /api/login you get the access key
1611 14:32 < jtanx> there's a three minute timeout on the key
1612 14:32 < jtanx> if you wish to invalidate the key
1613 14:33 < jtanx> you call 
1614 14:33 < jtanx>  /api/login?end
1615 14:34 < jtanx> you can force getting a key by also calling /api/login?force
1616 14:34 < james__> right. well it worked this time
1617 14:34 < james__> Thats weird
1618 14:34 < jtanx> so the only thing that the key prevents is stopping accidental concurrent use
1619 14:34 < james__> Fair enough
1620 14:35 < jtanx> Calling /api/login?force will force a new key to be generated and the old one to be invalidated
1621 14:35 < james__> Okay
1622 14:35 < jtanx> btw as I was working on unit testing
1623 14:35 < jtanx> I did a function to retrieve the json data
1624 14:36 < jtanx> http://mctx.us.to:8080/unit-tests/unit-tests.js
1625 14:37 < james__> I will have a look.  I have some buttons working and stuff. Working on putting them in a seperate script file for easier editing etc
1626 14:37 < james__> They don't seem to be playing nice at the moment
1627 14:37 < jtanx> ok
1628 14:38 < jtanx> how come it takes so much effort to get some buttons working
1629 14:39 < james__> Getting the css to mesh with the js
1630 14:40 < james__> I have buttons fine 
1631 14:40 < james__> And they work
1632 14:40 < jtanx> maybe you should get the functionality to work first
1633 14:40 < jtanx> with the ajax queries
1634 14:40 < jtanx> before worrying about styling them
1635 14:40 < james__> I have the functionality pretty much working
1636 14:41 < jtanx> so the querying works?
1637 14:41 < james__> But i want the styling to work before we scale it up
1638 14:41 < james__> That way its less hassle to fix it later
1639 14:41 < jtanx> could you post it to git?
1640 14:41 < jtanx> it'd be cool to have a look
1641 14:45 < james__> The way i am thinking about having it set out is having a central index.html which just imports all the js. The js will contain all the functionlity seperated in to similar functions. Ie. all the buttons in one script
1642 14:46 < jtanx> right
1643 14:46 < james__> That should allow for ease of scaling and editing
1644 14:46 < james__> Also changing id's and stuff
1645 15:46 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1646 19:25 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1647 21:09 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
1648 23:18 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1649 --- Day changed Fri Aug 30 2013
1650 09:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1651 09:16 -!- jtanx [[email protected]] has quit [EOF From client]
1652 14:15 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1653 17:06 < jtanx> say you want to perform a command
1654 17:06 < jtanx> eg move an actuator
1655 17:07 < jtanx> and suppose checks have to be made against other sensors to ensure that this command is good to go
1656 17:07 < jtanx> how are those checks going to be made?
1657 18:10 < sam_moore> The Actuator Handler will call some sanity check against the most recent sensor data
1658 18:11 < sam_moore> If they aren't, it will respond with some appropriate JSON or HTTP status code
1659 18:11 < sam_moore> eg: "Try again later when the pressure is in the right range", or "Don't do that you silly person"
1660 18:15 < jtanx> ._.
1661 18:21 < jtanx> I wonder if there's a way to pull from your git repository without creating the 'merge branch master from...' commits
1662 18:22 < sam_moore> I don't think so
1663 18:22 < jtanx> I tried playing with rebasing but it doesn't work out so well
1664 18:40 < jtanx> ok so I've committed some stuff to my repository that changes the handling of controls/actuators/login
1665 18:41 < jtanx> I'm not sure if it's the best way to do it
1666 18:41 < jtanx> though
1667 18:41 < jtanx> What I did was get rid of /api/login
1668 18:41 < jtanx> and instead have /api/control
1669 18:41 < jtanx> All of the control code (eg actuators but may be other controls? Start/stop the whole thing?) has been moved to controls.c
1670 18:42 < jtanx> You still need to supply username and password to access /api/control
1671 18:42 < jtanx> and what was previously called  the 'authorization key'  is now the control key (ie who has control)
1672 19:00 < sam_moore> Ok, I'll take a look at it later
1673 19:01 < sam_moore> Don't worry about the merge messages, it's not a big deal
1674 19:06 < jtanx> ok thanks
1675 20:27 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1676 22:21 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1677 23:03 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1678 --- Day changed Sat Aug 31 2013
1679 09:09 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1680 15:30 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1681 17:40 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1682 20:48 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1683 --- Day changed Sun Sep 01 2013
1684 09:11 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1685 14:07 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1686 14:17 < jtanx> it'd have been cool to have written then server in python
1687 14:19 < Callum> gah havent done much for this project this week. not sure what i should do either 
1688 14:19 < jtanx> hmm
1689 14:19 < Callum> so far behind in one of my units too. haha joys of uni
1690 14:19 < jtanx> lol
1691 14:20 < jtanx> werent we meant to get the camera stuff working or something
1692 14:21 < Callum> well yea but thats more rosher getting stuff working on his end. still not really sure what's going on. need to find an efficient way to transfer data (which would be directly streaming but it seemed adrian wanted some sort of processing)
1693 14:21 < Callum> guess i could start working on edge detection
1694 14:21 < jtanx> james hasn't got much done afaik
1695 14:21 < Callum> nah dont think he ahs
1696 14:22 < jtanx> but man I was looking at the javascript stuff
1697 14:22 < jtanx> and it's really annoying
1698 14:22 < jtanx> everything in javascript is asynchronous
1699 14:22 < jtanx> so you have a callback for an AJAX query, and it gets executed some time in the future
1700 14:23 < jtanx> it's really hard to pass variables to the callback and then also retrieve them 
1701 14:23 < Callum> hmm
1702 14:23 < jtanx> i'm probably not doing it in the right fashion or something
1703 14:28 < Callum> not sure. don't really understand this stuff myself. havent done much/any
1704 14:45 < jtanx> flask is so cool
1705 15:01 < jtanx> oh
1706 15:02 < jtanx> maybe we can use cookies to store authorization
1707 15:02 < jtanx> instead of in javascript
1708 15:02 < jtanx> hmm
1709 15:02 < jtanx> http://stackoverflow.com/questions/15722795/how-to-create-a-cookie-with-fastcgi-nginx-in-c
1710 15:57 < sam_moore> Maybe a cookie is better, but couldn't you have a global variable that the JavaScript code sets in the callback?
1711 15:57 -!- Irssi: #mctxuwa_softdev: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal]
1712 15:59 < sam_moore> Ok, I'll do the simulated "digital" sensor and actuator
1713 15:59 < sam_moore> We should make some kind of minimal gui in JavaScript
1714 16:00 < sam_moore> I'm not sure what James has done, but there's nothing under git
1715 16:02 < sam_moore> http://www.flotcharts.org/flot/examples/ajax/index.html is a good starting point for updating sensor graphs
1716 16:03 < sam_moore> jtanx: I wouldn't worry about the login/authentication too much for this week
1717 16:04 < jtanx> james said he got the buttons working but that's about it
1718 16:04 < jtanx> he's more concerned about issues with styling them than getting a fully fledged gui
1719 16:04 < sam_moore> I think actually having a gui is more important than having a pretty gui
1720 16:04 < sam_moore> At the moment anyway
1721 16:05 < jtanx> yeah
1722 16:05 < jtanx> it would be great to have *something*
1723 16:05 < jtanx> the problem with js
1724 16:05 < jtanx> is from what i've seen, the callback occurs in the jQuery file
1725 16:06 < jtanx> so you can't set global variables in say sensors.js
1726 16:06 < jtanx> and expect to be able to read/set them in the callback
1727 16:06 < sam_moore> Hmm, that's wierd
1728 16:06 < jtanx> what really shits me about javascript is variable handling
1729 16:06 < sam_moore> Hang on, let me have another look at the only project I ever used jQuery for... :P
1730 16:07 < jtanx> you can pass one/none/more than specified parameters
1731 16:07 < sam_moore> It was a chess game, so it should definietly be possible to modify variables in the callback function
1732 16:07 < jtanx> yeah there's probably a way, I just don't know it
1733 16:08 < jtanx> about the actuators
1734 16:08 < jtanx> I've already got something working in my repository
1735 16:08 < jtanx> but I don't really like how I've done it
1736 16:30 < sam_moore> I'm making a minimal gui (it will be able to plot something, and have a button); we can either ditch it or improve on it later
1737 16:31 < jtanx> sounds good
1738 16:35 < sam_moore> Callum: If you want to make a (really awful but possibly looking good enough at this stage for Adrian) "streaming" images thing
1739 16:35 < sam_moore> You can have your program continuously save to a file
1740 16:35 < sam_moore> And a html page that just has "<meta http-equiv="refresh" content="0">" in the header
1741 16:35 < sam_moore> With a link to the image
1742 16:36 < Callum> alright il look into it
1743 16:36 < sam_moore> It's absolutely aweful, but it will give the effect of a really laggy video
1744 16:36 < jtanx> nice :P
1745 16:36 < sam_moore> You can improve it (if you get time) by having 2 images instead of one, with a symbolic link to swap between them
1746 16:38 < sam_moore> I'll bring the raspberry pi with the webcam tomorrow and we'll put everything on it to show Adrian
1747 16:38 < jtanx> hehehe
1748 16:38 < jtanx> can you install ffserver on the raspi?
1749 16:39 < sam_moore> Probably
1750 16:40 < jtanx> actually
1751 16:41 < jtanx> does our code run on the raspi?
1752 16:50 < sam_moore> Yes, at the moment
1753 16:54 < Callum> how are we integrating my code into it?
1754 17:01 < sam_moore> Keep it as a seperate process for now
1755 17:01 < Callum> alright
1756 17:01 < sam_moore> I'll modify the "run.sh" script to start both of them
1757 17:01 < sam_moore> Sigh javascript
1758 17:01 < sam_moore> So useful and yet so horrible
1759 17:02 < sam_moore> Still, I think if we can get our heads around it it is actually a nice way to do this
1760 17:09 < jtanx> the camera thing or the api or both?
1761 17:24 < sam_moore> The API
1762 17:24 < Callum> ok so how do i link to the image? (
1763 17:24 < sam_moore> Just put a html file in the /server directory for now
1764 17:25 < sam_moore> With <img src="path_to_image"> in the body somewhere
1765 17:29 < Callum> where are we going to put the images?
1766 17:31 < sam_moore> /server/images (?)
1767 17:31 < sam_moore> Wherever it seems logical I guess
1768 17:33 < sam_moore> If either of you are available earlier on Monday, I'm free for pretty much the whole day
1769 17:33 < sam_moore> Do you want to meet earlier and actually do coding as a group?
1770 17:37 < sam_moore> Dammit why does javascript remove the [] brackets when printing string representations of arrays
1771 17:37 < sam_moore> How are you supposed to tell what dimensions the array has...
1772 17:37 < jtanx> if you want sample code of how I printed the array of sensor values
1773 17:37 < jtanx> see the unit tests
1774 17:37 < sam_moore> Ok, thanks
1775 17:37 < jtanx>    for (var i = 0; i < data.data.length; i++) {
1776 17:37 < jtanx>      result += data.data[i][0]  + ":" + data.data[i][1] + ", ";
1777 17:37 < jtanx>    }
1778 17:56 < Callum> ok well iv done trhat, i think. you should probably check it to make sure its right
1779 17:58 < Callum> sent pull request. and i'v got food so brb
1780 17:58 < sam_moore> Ok, thanks
1781 17:59 < sam_moore> jtanx: You're right, altering variables on a successful ajax call is a pain in the ass
1782 17:59 < jtanx> hehe
1783 17:59 < sam_moore> ... You can modify html attributes really easily though
1784 17:59 < jtanx> true
1785 17:59 < jtanx> that's what I was thinking
1786 17:59 < sam_moore> Must resist urge to store data in a comment
1787 17:59 < jtanx> have a hidden input field?
1788 18:01 < jtanx> I must say that the firebug debugger and inbuilt web console were both quite useful
1789 18:02 < sam_moore> Yes, I've got firebug running
1790 18:04 < jtanx> I was looking at flask and it was ridiculously easy to set up a similar API in python
1791 18:05 < sam_moore> Do you want to change to python then?
1792 18:06 < sam_moore> Don't we still have to do the javascript though?
1793 18:07 < sam_moore> The API we have at the moment isn't that terrible
1794 18:07 < jtanx> nah
1795 18:07 < jtanx> it's probably best to stick with what we have
1796 18:07 < jtanx> the javascript stuff would remain the same yeah
1797 18:09 < sam_moore> Ok
1798 18:26 < sam_moore> Right... you can update global variables on a successful AJAX request
1799 18:27 < sam_moore> If you put "var" in front of the variable in the global scope then the AJAX callback will just make a new local variable and modify that -_-
1800 18:27 < sam_moore> But if you Don't put the "var" there, it will work
1801 18:40 < jtanx> lol
1802 18:41 < jtanx> but using global variables in javascript can get.... messy
1803 18:41 < sam_moore> Mmm
1804 18:42 < sam_moore> But doing pretty much *anything* in javascript is messy
1805 18:42 < jtanx> yeah
1806 18:42 < jtanx> true that
1807 18:43 < sam_moore> I wonder...
1808 18:43 < sam_moore> Should we just have one html page for each sensor/actuator
1809 18:43 < sam_moore> And then the user can open multiple tabs?
1810 18:45 < sam_moore> That's probably not very nice though
1811 18:46 < sam_moore> I think we should return data about multiple sensors at a time
1812 18:51 < jtanx> you'd probably want it all on one page
1813 18:51 < sam_moore> Yeah
1814 18:51 < jtanx> how many sensors are we talking about again
1815 18:51 < sam_moore> 6 or 7 I think, + a camera
1816 18:51 < jtanx> oh yeah
1817 18:51 < sam_moore> Oh well, we can redesign it later
1818 18:51 < jtanx> I guess we can design for max 7
1819 18:52 < sam_moore> But it might be a good idea to query multiple sensors in one ajax request
1820 18:53 < jtanx> yep
1821 18:53 < jtanx> supply more than one id in a go?
1822 18:53 < jtanx> could have an array (max size 7) that holds all the sensors you want to get data for
1823 18:53 < jtanx> i guess
1824 18:55 < sam_moore> It's probably more flexible to just add a "getall" key to the sensor module
1825 18:57 < jtanx> oh yeah
1826 18:57 < jtanx> I'm free until 12 tomorrow
1827 18:57 < jtanx> do you want to work together before that?
1828 18:58 < sam_moore> Sure
1829 18:59 < sam_moore> Try G19 again, but if that doesn't work we can go to the physics lab, or the computer science labs
1830 19:01 < jtanx> yeah ok
1831 19:02 < jtanx> what time do you want to start?
1832 19:04 < sam_moore> I'll probably get in around 9 or 10, depending on how much sleep I get
1833 19:04 < sam_moore> Let's say 10:00
1834 19:05 < sam_moore> Got to go, I'll be back later
1835 19:05 < jtanx> ok
1836 21:35 < sam_moore> I'm just going to use the same Sensor stuff for digital sensors
1837 21:36 < sam_moore> Adding a second type of sensor seems needlessly complicated
1838 21:36 < sam_moore> 1 = on and 0 = off
1839 21:37 < sam_moore> Probably do the same for actuators (just have some sanity checks on the values you can set, both at the client and the server)
1840 21:38 < jtanx> usually I'd just say 0 is off and not 0 is on
1841 21:38 < sam_moore> Haha, fair enough
1842 21:39 < jtanx> I kinda hate over-checking stuff :P
1843 21:39 < sam_moore> The actual GetData function has to return something reasonably sane though
1844 21:39 < sam_moore> It's easy to just make it only return 0 or 1
1845 21:39 < jtanx> oh I was more talking about setting the value of the actuator 
1846 21:39 < sam_moore> Right
1847 21:40 < sam_moore> We should probably check for 0 or 1 anyway
1848 21:40 < sam_moore> In case the user does something dumb
1849 21:40 < jtanx> well
1850 21:40 < sam_moore> Like think they are setting an analog sensor and put in like "200"
1851 21:40 < jtanx> it should be the js code that's setting it
1852 21:41 < jtanx> so if you write the code properly it shoul be ok
1853 21:41 < sam_moore> "should be OK"...
1854 21:41 < jtanx> you shouldn't access the api directly
1855 21:41 < sam_moore> Alright, we'll see, but it's like, 1/2 a line of code to check :P
1856 21:41 < sam_moore> Redundancy and all that
1857 21:41 < jtanx> but even if they entered 200
1858 21:41 < jtanx> well so what
1859 21:41 < sam_moore> Yeah, but people *can* access the API directly
1860 21:41 < jtanx> it'd just represet 1
1861 21:42 < jtanx> represent
1862 21:42 < jtanx> *
1863 21:42 < sam_moore> How does the server know the difference between someone typing the URL and an AJAX request to the URL?
1864 21:42 < jtanx> yeah
1865 21:42 < sam_moore> Someone could go view source, "How can I break this... ah, what happens if I pass stupid values directly to the API"
1866 21:42 < jtanx> well if you define that 0 is off and not zero is on
1867 21:43 < jtanx> then it meets specs :P
1868 21:43 < sam_moore> Ok, I suppose it doesn't really matter
1869 21:44 < sam_moore> I respectfully disagree with the idea of having too many checks :P
1870 21:44 < sam_moore> Unless we went "while (true) DoCheck();" or something like that
1871 21:44 < sam_moore> That would be dumb
1872 21:44 < jtanx> hahaha
1873 21:45 < jtanx> but sometimes it gets really messy to maintain when you have that many checks
1874 21:45 < jtanx> and then when you want to modify something it's a real pain
1875 21:45 < jtanx> and really easy to break
1876 21:45 < sam_moore> True, but a bounds check isn't that bad
1877 21:46 < jtanx> yrue
1878 21:46 < sam_moore> I mean, you have to convert the value that isn't zero to an "on" anyway, which requires a check
1879 21:46 < jtanx> not really
1880 21:46 < sam_moore> Depends on the actuator
1881 21:46 < jtanx> you check if !value
1882 21:47 < sam_moore> Alright
1883 21:58 < jtanx> do you think there should be a stop/start method?
1884 21:58 < jtanx> eg start the experiment
1885 21:58 < jtanx> stop the experiment
1886 22:28 < sam_moore> Yes, probably
1887 22:28 < sam_moore> The stuff I wrote for Thread Exit conditions may actually help there...
1888 22:29 < sam_moore> Remove the bit where the FCGI loop exits though
1889 22:29 < jtanx> yeah 
1890 22:41 -!- Callum [[email protected]] has quit [EOF From client]
1891 23:09 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1892 --- Day changed Mon Sep 02 2013
1893 07:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1894 08:33 < sam_moore> Hi
1895 08:33 < sam_moore> I managed to get a reasonable sensor plotting GUI done
1896 08:35 < sam_moore> So, adrian wanted: 1) A digital sensor simulation (done) 2) Sensors plotted in GUI (done) 3) A test actuator in the GUI 4) Camera images in the GUI (sort of done, kind of)
1897 08:35 < sam_moore> Was there anything else?
1898 08:38 < sam_moore> I have to go to Uni, I'll be in G19 otherwise I'll send an email
1899 08:38 < sam_moore> See you
1900 08:42 < jtanx> ok then
1901 09:02 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1902 09:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1903 09:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1904 13:06 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1905 13:12 -!- james__ [[email protected]] has joined #mctxuwa_softdev
1906 13:15 < jtanx> hey
1907 13:18 < james__> hey
1908 13:18 < james__> I have the AJAX call working i am pretty sure
1909 13:19 < jtanx> ok
1910 13:19 < james__> Do you know if we have the beaglebones in yet?
1911 13:19 < jtanx> I don't know
1912 13:19 < jtanx> it should be ready soon though
1913 13:19 < jtanx> anyway, sam got a gui with graphs semi working 
1914 13:20 < jtanx> could you update your git repository with what you've done?
1915 13:28 -!- james__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1916 13:31 < jtanx> :(
1917 13:31 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1918 18:12 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1919 18:46 -!- Callum [[email protected]] has joined #mctxuwa_softdev
1920 19:17 -!- Callum [[email protected]] has quit [Ping timeout]
1921 21:04 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1922 --- Day changed Tue Sep 03 2013
1923 17:23 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1924 21:29 -!- jtanx [[email protected]] has quit [Ping timeout]
1925 21:35 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1926 21:35 -!- jtanx_ is now known as jtanx
1927 22:10 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1928 --- Day changed Wed Sep 04 2013
1929 07:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1930 08:35 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
1931 08:35 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1932 08:49 -!- jtanx [[email protected]] has quit [Ping timeout]
1933 08:51 -!- MctxBot [[email protected]] has quit [Ping timeout]
1934 09:02 -!- jtanx_ is now known as jtanx
1935 09:03 -!- MctxBot_ is now known as MctxBot
1936 11:54 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1937 15:32 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1938 16:00 -!- jtanx [[email protected]] has quit [Ping timeout]
1939 16:00 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
1940 16:00 -!- jtanx_ is now known as jtanx
1941 16:21 -!- jtanx [[email protected]] has quit [Ping timeout]
1942 17:26 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1943 20:49 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1944 --- Day changed Thu Sep 05 2013
1945 08:19 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1946 09:34 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1947 13:22 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1948 18:51 < jtanx> hm, so to get clock_gettime to work, you need to use std=gnu99 instead of std=c99
1949 18:52 < jtanx> do you think we should just stick with gettimeofday?
1950 21:46 -!- jtanx [[email protected]] has quit [":3"]
1951 --- Day changed Fri Sep 06 2013
1952 09:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1953 12:05 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1954 13:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1955 16:05 < jtanx> I was just thinking, what sort of identification information is needed from the server?
1956 16:05 < jtanx> The gui should have some understanding of what sort of sensors/actuators it needs to display
1957 16:10 < jtanx> it might be enough to say this is API version x
1958 16:10 < jtanx> and at version x, it's agreed that these id values correspond to these sensors/actuators etc?
1959 16:19 < jtanx> anyway, what I've done for now is if asked, the api will list the sensor/actuator ids and the corresponding human readable string
1960 16:19 < jtanx> api/?sensors&actuators
1961 18:06 < jtanx> also, what do you think of keeping track of the number of points stored
1962 18:07 < jtanx> then you can allow the user to request from where they want to retrieve data from and how many to retrieve
1963 18:08 < jtanx> the only problem is that it wouldn't be time based, but based on the number of data points recorded
1964 18:08 < jtanx> this method is simpler because you now the offset to use with fseek
1965 18:08 < jtanx> if it's time based you have to search the data for the correct point
1966 19:51 < sam_moore> All the above makes good sense
1967 19:52 < sam_moore> If we can make a working "request X number of points" first instead of "request from time T onwards", we might be able to convert the latter to the former if necessary
1968 20:04 < jtanx> ok I just submitted a pull request for some stuff
1969 20:04 < jtanx> mostly the identification stuff and some reordering
1970 20:04 < jtanx> FCGI_RejectJSON now requires that you give a description explaining why
1971 20:05 < jtanx> when RejectJSOn is called, it's always logged along with the description, so some of the current log messages within the handler functions may be redundant
1972 21:11 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
1973 --- Day changed Sat Sep 07 2013
1974 10:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
1975 18:29 < jtanx> hmm
1976 18:29 < jtanx> what if you had two file pointers to the same file
1977 18:29 < jtanx> one read only, one write only
1978 18:29 < jtanx> then if you also kept track of how many points were written to the file
1979 18:29 < jtanx> you don't need to have mutexes anymore
1980 18:30 < jtanx> as long as you write the read/write calls carefully
1981 18:44 < jtanx> ahp, may have spoken too soon
1982 18:44 < jtanx> you'd still need a mutex around the read/write from/to the counter
1983 18:45 < jtanx> I think...
1984 19:07 < jtanx> but it might still be a good idea
1985 21:38 < jtanx> I went the simple route
1986 21:53 < jtanx> what I've got: /api/sensors?id=x&from=y&count=z
1987 21:54 < jtanx> In dump mode:
1988 21:54 < jtanx> If from < 0, then return from start, else from the given index (0-indexed)
1989 21:54 < jtanx> if count < 0, then return all points, else return /at most/ that many points
1990 21:55 < jtanx> in normal mode:
1991 21:55 < jtanx> if from < 0, then return from the end (return the most recent points)
1992 21:55 < jtanx> if count < 0, then return at most the default amount (SENSOR_QUERYBUFSIZ)
1993 21:56 < jtanx> otherwise return /at most/ that many points
1994 21:56 < jtanx> oh ya, if from >= 0 then return from that indicated index
1995 21:57 < jtanx> it's only in my git repository for now because I haven't tested it enough and I'm still not sure how I should go about integrating it with the current code
1996 21:58 < jtanx> (I basically rewrote Sensor_Handler and it has less error checks on the input; not sure if they're necessary or not)
1997 21:59 < jtanx> Since requesting a huge range could impact on sensor readings due to the mutex, it may be better to at least restrict dumps to when the experiment is not 'running'
1998 22:01 -!- jtanx [[email protected]] has quit ["~ that's it for now! ~"]
1999 --- Day changed Sun Sep 08 2013
2000 11:28 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2001 14:50 -!- Callum [[email protected]] has joined #mctxuwa_softdev
2002 17:55 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
2003 18:06 < Callum_> what was the server stuff you said to install? also what packages do i need?
2004 18:07 -!- Callum_ [[email protected]] has quit [EOF From client]
2005 18:07 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
2006 18:09 -!- Callum [[email protected]] has quit [Ping timeout]
2007 18:09 -!- Callum_ is now known as Callum
2008 18:21 < jtanx> if you want to install the server, you need at least the 'nginx' and 'spawn-fcgi' packages
2009 18:21 < jtanx> one nginx is installed you need to copy the config files from the git repository in
2010 21:14 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2011 21:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2012 22:36 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2013 22:38 -!- Callum [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2014 --- Day changed Mon Sep 09 2013
2015 09:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2016 09:59 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
2017 10:13 -!- jtanx [[email protected]] has quit [Ping timeout]
2018 10:54 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2019 11:30 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
2020 13:27 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2021 13:48 -!- jtanx [[email protected]] has quit [Ping timeout]
2022 14:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2023 15:25 -!- jtanx [[email protected]] has quit [Ping timeout]
2024 15:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2025 15:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2026 20:33 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2027 21:01 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2028 --- Day changed Tue Sep 10 2013
2029 17:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2030 17:25 < jtanx> it looks like we do need an sd card, at least to install the os onto it
2031 17:26 < jtanx> http://beagleboard.org/Getting%20Started#update
2032 17:41 < jtanx> http://avedo.net/653/flashing-ubuntu-13-04-or-debian-wheezy-to-the-beaglebone-black-emmc/
2033 17:42 < sam_moore> Ok, we should write a BOM for next week then
2034 17:42 < sam_moore> 1x SD Card
2035 17:44 < jtanx> from what I understand
2036 17:45 < jtanx> you write an image to the sd card
2037 17:45 < jtanx> boot off the sd card
2038 17:45 < jtanx> then you can write another image directly too the internal storage
2039 17:45 < jtanx> after that you don't need the sd card any more
2040 17:46 < sam_moore> Alright
2041 17:46 < jtanx> http://www.armhf.com/index.php/boards/beaglebone-black/
2042 17:47 < jtanx> any preference for ubuntu or debian?
2043 17:48 < sam_moore> As a debian user, I'd have to say debian :P
2044 17:49 < jtanx> hehe
2045 17:49 < sam_moore> If it works on debian stable, we know it will work for at least the next 6 years
2046 17:49 < jtanx> yup
2047 17:49 < jtanx> debian should be fine
2048 17:53 < jtanx> *correction; we need a microsd card
2049 17:56 < jtanx> that's at least 2GB in size
2050 17:57 < sam_moore> Ok
2051 18:04 < jtanx> haha it's cheaper to buy a 4gb one than a 2gb one
2052 18:35 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2053 19:11 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2054 20:15 < jtanx> Well I can confirm that angstrom doesn't have nginx precompiled - http://www.angstrom-distribution.org/repo/
2055 20:57 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2056 --- Day changed Wed Sep 11 2013
2057 10:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2058 11:10 -!- jtanx [[email protected]] has quit [Ping timeout]
2059 15:58 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2060 15:58 < jtanx> urgh
2061 15:58 < jtanx> it took so long just getting internet access to the bbb
2062 16:01 < jtanx> dhcp/dns issues
2063 16:01 < jtanx> the debian image on the microsd is set to static ip 192.168.0.7
2064 16:02 < jtanx>  /etc/resolv.conf should have the uwa nameservers in it, but it may have been rewritten by resolvconf
2065 16:02 < jtanx> I've left it in g19
2066 16:51 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2067 17:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2068 19:32 < jtanx> I've moved the 'current_time', 'start_time' and 'running_time' to the identify module instead of sticking it on every json response, because it's probably not information that will be required most of the time
2069 19:37 < jtanx> actually, we may have to rethink those, especially if we introduce start/stop control
2070 20:38 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2071 --- Day changed Thu Sep 12 2013
2072 08:49 -!- MctxBot [[email protected]] has quit [Connection reset by peer]
2073 09:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2074 09:36 < sam_moore> I think I have some time after the tutorial today to work on stuff
2075 09:36 < sam_moore> I take it we have the bbb now?
2076 09:37 < sam_moore> I'll bring that crappy webcam
2077 09:37 < sam_moore> Maybe look into sending images as part of the API, see if it's feasable to do it that way
2078 09:38 < sam_moore> I think we can introduce start/stop control fairly easily
2079 09:40 < sam_moore> "Mush Mush"
2080 09:40 < sam_moore> Heh
2081 09:41 < sam_moore> To reduce the load on the client, we might be able to send averaged data points instead of every data point
2082 09:41 < sam_moore> You specify "averages per point"
2083 09:42 < sam_moore> So each [time, value] pair is actually an average of X recordings
2084 09:42 < sam_moore> In fact it's better to send [mean_time, mean_value, std_dev]
2085 09:42 < sam_moore> The std_dev gives you an idea of noise and/or if the value is changing a lot
2086 09:43 < sam_moore> And of course you can always specify a single average and it becomes equivelant to what we currently do
2087 09:50 < jtanx> yeah
2088 09:50 < jtanx> I'm free after the tute
2089 09:50 < jtanx> I'm bringing in a router to make it easier
2090 09:50 < jtanx> to work on the bbb together
2091 09:51 < jtanx> yesterday it was so painful trying to get shit working 
2092 09:51 < jtanx> dhcp issues, dns issues, internet connection sharing issues...
2093 09:51 < jtanx> (mostly the fault of my own computer though)
2094 09:51 < jtanx> btw I'm working on adding an extra function to FCGI to makeit easier to parse parameters
2095 09:51 < jtanx> (hoepfully)
2096 09:55 < jtanx> gtg see you at the tute
2097 09:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2098 18:24 -!- Callum [[email protected]] has joined #mctxuwa_softdev
2099 18:26 < Callum> would be easier to talk here...if everyone was on
2100 18:35 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2101 18:41 < jtanx> did you bring the bbb home?
2102 18:43 < sam_moore> Yep
2103 18:44 < sam_moore> I'll put it back tomorrow morning
2104 18:49 < jtanx> ok
2105 19:15 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
2106 19:28 -!- Callum [[email protected]] has quit [Ping timeout]
2107 19:47 < jtanx> I'm so tempted to use bitflags for that request function
2108 19:52 < jtanx> one thing that I need to do is to sanitise json string fields
2109 20:18 < sam_moore> Sanitise? As in "make sane" or "make clean"?
2110 20:18 < sam_moore> Um... if you think bitflags are necessary, I fully support you :P
2111 20:19 < jtanx> as in
2112 20:19 < jtanx> If I allow FCGI_JSONPair to also be passed a format string
2113 20:19 < jtanx> then having stuff like \ or " or newline characters for eg in the string
2114 20:20 < jtanx> is not a good idea
2115 20:20 < sam_moore> Hmm
2116 20:20 < jtanx> it's sorta like this:
2117 20:20 < sam_moore> Well, writing the function to print out data (either as TSV or JSON)
2118 20:20 < sam_moore> I've only been using FCGI_PrintRaw
2119 20:20 < jtanx> yeah
2120 20:20 < jtanx> but right now, you're logging messages in Server_handler
2121 20:20 < jtanx> about invalid values
2122 20:21 < sam_moore> Yes, I'm not sure how to deal with that
2123 20:21 < jtanx> Sensor_handler*
2124 20:21 < jtanx> so
2125 20:21 < jtanx> eg Log(LOGERR, "Require \"all\" or an integer value: %s = %s", key, value);
2126 20:21 < sam_moore> Yes
2127 20:21 < jtanx> if I wanted to send that back to the client in FCGI_RejectJSON
2128 20:21 < jtanx> there's the potential (...) that the user could hvae included a " in the value
2129 20:22 < jtanx> so if you return it as part of your json response, then suddenly it's broken
2130 20:22 < sam_moore> Oh, that sucks
2131 20:23 < sam_moore> Perhaps treat Log messages seperately from JSON responses?
2132 20:23 < jtanx> eg:  "description":" required an id, got 'blah-stray"'"
2133 20:23 < jtanx> yeah
2134 20:24 < jtanx> What I could do is just replace any special characters with space 
2135 20:24 < jtanx> and return that in description
2136 20:24 < jtanx> but keep the actual value in log
2137 20:24 < sam_moore> Maybe
2138 20:24 < sam_moore> You could also call FCGI_RejectJSON as soon as you get a special character
2139 20:25 < sam_moore> Since we shouldn't have any key/values that use them
2140 20:25 < sam_moore> (I think :P)
2141 20:25 < jtanx> lol
2142 20:25 < sam_moore> Whatever seems best
2143 20:25 < jtanx> let me think about it some more
2144 20:25 < sam_moore> Yeah, fair enough
2145 20:25 < sam_moore> Um, another thing (sorry) is error messages that you might get independent of any request
2146 20:26 < sam_moore> Like you suddenly have an I/O error on a file
2147 20:26 < sam_moore> Currently we handle that with Fatal
2148 20:26 < sam_moore> Which it would be convenient to keep; but instead of terminating the whole program, we need to notify the client somehow
2149 20:26 < jtanx> that won't happen until the next request
2150 20:27 < jtanx> what you could do is keep it exiting
2151 20:27 < jtanx> when that happens, nginx sends 502 bad gateway
2152 20:27 < jtanx> then if that's detected, send a link to the log file
2153 20:27 < sam_moore> Yeah, that seems good
2154 20:27 < jtanx> and a method to restart the software
2155 20:28 < sam_moore> Do we want to notify the client of non-fatal errors or warnings though?
2156 20:28 < sam_moore> Hmm
2157 20:29 < jtanx> hmm
2158 20:29 < jtanx> probably a good idea
2159 20:29 < jtanx> but how
2160 20:29 < sam_moore> The client could periodically request the log file and deal with messages?
2161 20:30 < jtanx> It could just display it I guess
2162 20:30 < jtanx> onus on the user to take action if required
2163 20:30 < sam_moore> Sure, an alert might be nice though
2164 20:30 < sam_moore> Perhaps have an extra log file that just has the most recent message in it (with a timestamp)
2165 20:31 < jtanx> you could perform a regex on the text and highlight lines with warning or something
2166 20:31 < sam_moore> The client just periodically looks at that and if it's a new message can alert
2167 20:31 < sam_moore> Yeah that would work, as long as the file doesn't get too big
2168 20:31 < sam_moore> It probably won't
2169 20:31 < jtanx> well you could autoscroll it anyway
2170 20:32 < jtanx> but ok maybe that's getting a bit ahead of ourselves
2171 20:32 < sam_moore> Yeah, sure
2172 20:32 < sam_moore> I'll get back to rewriting 90% of the sensor code :P
2173 20:32 < jtanx> haha
2174 20:32 < jtanx> currently, I've got
2175 20:32 < jtanx> bool FCGI_ParseRequest(FCGIContext *context, char *params, FCGIValue values[], size_t count);
2176 20:32 < jtanx> (any better suggestion for FCGIValue?)
2177 20:32 < jtanx> (the name that is)
2178 20:33 < jtanx> with 
2179 20:33 < sam_moore> That's probably fine
2180 20:33 < jtanx> typedef struct FCGIValue {
2181 20:33 < jtanx>  const char *key;
2182 20:33 < jtanx>  void *value;
2183 20:33 < jtanx>  unsigned flags;
2184 20:33 < jtanx> } FCGIValue;
2185 20:33 < jtanx> you then do
2186 20:33 < jtanx> something like:
2187 20:33 < jtanx> FCGIValue values[2] = {{"sensors", &ident_sensors, FCGI_REQUIRED(FCGI_BOOL_T)},
2188 20:33 < jtanx>                                   {"actuators", &ident_actuators, FCGI_BOOL_T}};
2189 20:33 < sam_moore> Looks good
2190 20:33 < jtanx> although I'm open to suggestions on those type names too
2191 20:34 < jtanx> if you really have to
2192 20:34 < jtanx> you can do something like FCGI_RECEIVED(values[0].flags)
2193 20:34 < jtanx> to check if you received the argument or not
2194 20:34 < sam_moore> If it's not too hard to implement, then OK
2195 20:35 < jtanx> ?
2196 20:35 < sam_moore> That looks reasonably nice
2197 20:35 < jtanx> the #defines look less so:
2198 20:35 < jtanx> #define FCGI_PARAM_REQUIRED (1 << 0)
2199 20:35 < jtanx> #define FCGI_PARAM_RECEIVED (1 << 1)
2200 20:35 < jtanx> #define FCGI_BOOL_T (1 << 2)
2201 20:35 < jtanx> #define FCGI_LONG_T (1 << 3)
2202 20:35 < jtanx> #define FCGI_DOUBLE_T (1 << 4)
2203 20:35 < jtanx> #define FCGI_STRING_T (1 << 5)
2204 20:35 < jtanx> #define FCGI_REQUIRED(x) ((x) | FCGI_PARAM_REQUIRED)
2205 20:35 < jtanx> #define FCGI_IS_REQUIRED(x) ((x) & FCGI_PARAM_REQUIRED)
2206 20:35 < jtanx> #define FCGI_RECEIVED(x) ((x) & FCGI_PARAM_RECEIVED)
2207 20:35 < jtanx> #define FCGI_TYPE(x) ((x) & ~(FCGI_PARAM_REQUIRED | FCGI_PARAM_RECEIVED))
2208 20:35 < sam_moore> In fact it's similar to how you use select(2)
2209 20:35 < sam_moore> Wow, macros
2210 20:35 < jtanx> :P
2211 20:35 < jtanx> makes life easier
2212 20:36 < sam_moore> Alright, this is C
2213 20:36 < sam_moore> Yeah, FCGI_RECEIVED(values[i].flags) looks nice (from the point of view of actually using it anyway)
2214 20:37 < jtanx> yeah it's ok
2215 20:37 < jtanx> the only stickler is that hardcoded index
2216 20:37 < jtanx> can't really do much about that though
2217 20:37 < sam_moore> I can put an enum in the function
2218 20:38 < jtanx> if you want; it might be more work to maintain the enum than anything though
2219 20:39 < jtanx> but yeah, essentially if you require a parameter, you surround the type in FCGI_REQUIRED()
2220 20:39 < jtanx> hopefully that part was clear
2221 20:39 < sam_moore> Yep, I'm happy with that
2222 20:39 < jtanx> cool
2223 20:43 < jtanx> for the bool value, what behaviour do you think is better
2224 20:43 < jtanx> always set the value to true, or invert the current value
2225 20:44 < jtanx> right now it's set to always be true
2226 21:06 < sam_moore> Um... always set to true?
2227 21:09 < jtanx> yeah
2228 21:29 < jtanx> oh
2229 21:30 < jtanx> well I didn't need to escape after all
2230 21:30 < jtanx> If you do something like this: http://mctx.us.to:8080/api?afa%22%22%22%22
2231 21:30 < jtanx> it gets url encoded
2232 21:30 < jtanx> http://mctx.us.to:8080/api?afa""""
2233 21:30 < jtanx> I wonder if that's guaranteed
2234 21:32 < jtanx> well, apparently it's not because IE doesn't escape it for you
2235 21:32 < jtanx> so I did need to escape 
2236 21:33 < sam_moore> There's no escape
2237 21:46 < jtanx> wait wat
2238 21:59 < sam_moore> (It's a pun)
2239 22:00 < sam_moore> So I've made a DataFile structure to isolate it a bit more from the higher level Sensor related stuff
2240 22:00 < sam_moore> Hopefully things make more sense
2241 22:00 < sam_moore> I put in 2 seperate FILE* as well
2242 22:00 < sam_moore> And got rid of the confusing "fill a buffer then dump the buffer to a file" loop
2243 22:01 < sam_moore> Now it just writes each point to a file
2244 22:01 < sam_moore> Hopefully it's thread safe enough
2245 22:01 < sam_moore> Now... I just need to simplify the Sensor_Handler function...
2246 22:02 < jtanx> > (It's a pun) 
2247 22:02  * jtanx facepalm
2248 22:03 < jtanx> hoho
2249 22:03 < jtanx> ok 
2250 22:03 < jtanx> I'll submit what I've done so far to git
2251 22:08 < jtanx> callum
2252 22:08 < jtanx> that code you submitted
2253 22:08 < jtanx> I don't think it's right
2254 22:08 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
2255 22:09 < jtanx> the stuff with g_sensor_names, that's the human readable name of each sensor
2256 22:10 < sam_moore> I've changed the name and how the sanity check gets called, but I've left the body unimplemented for now
2257 22:12 < jtanx> it's with the pull request he submitted ~30mins ago
2258 22:12 < sam_moore> Oh, ok
2259 22:13 < sam_moore> Good thing I made a new branch for my changes
2260 22:14 < jtanx> the pull request isn't merged yet
2261 22:15 < sam_moore> Yeah, I don't think we should merge that, sorry Callum
2262 22:17 < jtanx> ok just submitted the pull request
2263 22:17 < sam_moore> I never put documentation on g_sensor_names I guess, sorry
2264 22:17 < jtanx> I think I did though
2265 22:17 < jtanx> but in the header file
2266 22:18 < jtanx> which is annoying :/
2267 22:18 < jtanx> (as in there's more than one spot to put documentation)
2268 22:19 < sam_moore> Yeah... does one overwrite another?
2269 22:19 < sam_moore> I'll just copy paste the same thing into the .c file
2270 22:19 < jtanx> No idea how doxygen handles that
2271 22:20 < sam_moore> I wonder how much fun I'll have merging these branches...
2272 22:20 < jtanx> hehe
2273 22:20 < jtanx> I'm not really sure if FCGI_ParseRequest will be that helpful or not
2274 22:20 < jtanx> if you find it doesn't really help then we can scrap it
2275 22:21 < sam_moore> Well it makes sense to seperate the code for getting key,value pairs from the code that does stuff with them
2276 22:23 < jtanx> I guess
2277 22:23 < sam_moore> I've basically moved a lot of functionality from sensor.c into a new file data.c under functions with the prefix "Data_"
2278 22:24 < jtanx> ok
2279 22:24 < sam_moore> data.c doesn't care anything about what the data is or where it came from, it just wraps around saving/reading/selecting ranges of DataPoints
2280 22:25 < jtanx> sounds like a good idea
2281 22:25 < jtanx> it might be of use in actuator code I guess
2282 22:25 < sam_moore> Yeah, there's a DataFile structure that basically wraps around the binary file
2283 22:25 < sam_moore> Yes, I was thinking that too
2284 22:25 < sam_moore> Because we'll probably want to store DataPoints when an actuator gets changed
2285 22:26 < jtanx> yeah true
2286 22:27 < sam_moore> If the idea about using 2 FILE* is right... I don't think we really need any mutexes?
2287 22:28 < sam_moore> There is an index that gets incremented, but since only one thread can write to it, the worst that can happen is you return one (maybe two at the extreme) less point than actually exists
2288 22:29 < sam_moore> If you had 2 threads incrementing the index you'd need a mutex though
2289 22:29 < jtanx> the problem is that setting a value is not guaranteed to be atomic
2290 22:29 < jtanx>  i think
2291 22:29 < sam_moore> Yes, sure
2292 22:29 < jtanx> so while setting and you read it it could be indeterminate
2293 22:29 < sam_moore> Mmm
2294 22:30 < jtanx> I think you need mutexes around reading/writing the points_written(?)
2295 22:30 < jtanx> index
2296 22:30 < jtanx> but that's it
2297 22:31 < jtanx> http://stackoverflow.com/questions/54188/are-c-reads-and-writes-of-an-int-atomic
2298 22:31 < sam_moore> I'm not sure you do if you are writing in one thread and reading in another
2299 22:31 < sam_moore> Ah, stackoverflow, OK
2300 22:32 < jtanx> it's actually very architecture specific
2301 22:32 < sam_moore> Yeah "Yes, no, hmmm, well it depends" is probably right
2302 22:32 < jtanx> haha
2303 22:32 < sam_moore> Well... there are no mutexes at the moment, but maybe I should get around to putting them in
2304 22:32 < sam_moore> I think I had one thread writing and another reading in my parallel programming assignment and got full marks :S
2305 22:33 < sam_moore> Threads are strange and magical
2306 22:33 < jtanx> hey well it probably works 99% of the time
2307 22:34 < sam_moore> Ah, it probably works if the size of the integer is smaller than the bus
2308 22:34 < sam_moore> smaller or equal
2309 22:34 < jtanx> too bad linux doesn't have something like InterlockedExchange
2310 22:35 < sam_moore> I'll add mutexes in later then
2311 22:35 < jtanx> One thing I liked about C++ was auto locks
2312 22:36 < jtanx> (you could call some lock function and once that scope ended the lock ended too)
2313 22:36 < sam_moore> That's nice
2314 22:40 < jtanx> Ok, that's all I'm probably going to get done today
2315 22:41 < sam_moore> Yeah, thanks
2316 22:42 < jtanx> what's with the meeting tomorrow though
2317 22:43 < sam_moore> I'm busy from 2:00pm until at least 4:00pm (maybe later)
2318 22:43 < sam_moore> But I think I should be preparing for something before 2:00pm
2319 22:44 < jtanx> ok, I'll probably come in around 1.30pm so I can work with Callum, and I'll stay on until whatever time
2320 22:44 < sam_moore> Alright
2321 22:45 < sam_moore> Check github in the morning, I'll push all my changes
2322 22:45 < jtanx> ok I'll do that
2323 22:45 < sam_moore> Hopefully they make sense, otherwise you can change everything back :P
2324 22:45 < sam_moore> The wonders of git
2325 22:45 < jtanx> haha I'm sure it'll make sense
2326 22:46 < jtanx> after staring for a while
2327 22:46 < sam_moore> Yeah it should be a bit simpler
2328 22:46 < jtanx> thanks
2329 22:47 < jtanx> see you tomorrow (probably)
2330 22:48 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2331 23:28 -!- Callum_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2332 --- Day changed Fri Sep 13 2013
2333 08:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2334 08:31 < jtanx> oh yeah, I forgot to restart the bot :P
2335 08:31 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2336 08:53 < sam_moore> So, using 2 FILE* causes some problems, I recommend we just use 1
2337 08:54 < sam_moore> In theory the operating system is supposed to use locks when multiple processes have access to the same file
2338 08:54 < sam_moore> But... 
2339 08:54 < sam_moore> It probably doesn't work with threads
2340 08:55 < sam_moore> I'm not sure exactly what goes wrong, but using 1 works and isn't really going to be slower (if the OS uses locks then that probably has a similar overhead to using a mutex)
2341 08:59 < jtanx> yeah, let's stick to one then
2342 09:00 < jtanx> there's still a few bugs around I think
2343 09:00 < sam_moore> Probably
2344 09:01 < sam_moore> I put valgrind back in, I got rid of a lot last night
2345 09:01 < jtanx> nice
2346 09:01 < sam_moore> Although I probably introduced them in the first place
2347 09:01 < jtanx> what was with that mem leak in fastcgi code?
2348 09:03 < sam_moore> Oh, that wasn't a memory leak, it was an uninitialised value
2349 09:04 < sam_moore> I thought I'd be clever and use sizeof() on the FCGIValue array
2350 09:04 < sam_moore> But I forgot that the actual number of elements is not just sizeof()
2351 09:04 < sam_moore> It's sizeof(array) / sizeof(element)
2352 09:04 < jtanx> oh right haha
2353 09:05 < sam_moore> So the refactored code basically does the same thing
2354 09:05 < sam_moore> But hopefully it's a bit cleaner
2355 09:05 < jtanx> yep
2356 09:05 < jtanx> it's pretty good
2357 09:06 < jtanx> when you get an invalid id or format, do you want to reject that? 
2358 09:07 < sam_moore> Yeah, I wasn't sure what I should do there, but I think Sensor_Handler is the only place you can really deal with that
2359 09:07 < jtanx> yeah
2360 09:07 < sam_moore> I did have it calling FCGI_RejectJSON if the sensor id was invalid
2361 09:08 < jtanx> the current code on git just calls Log
2362 09:08 < sam_moore> But I must have done something wrong, because the normal JSON was getting printed just after that
2363 09:08 < sam_moore> So I removed it
2364 09:08 < jtanx> oh yeah
2365 09:08 < jtanx> you have to return after FCGI_RejectJSON
2366 09:08 < sam_moore> Ah
2367 09:08 < sam_moore> Durr
2368 09:08 < jtanx> :P
2369 09:09 < jtanx> anyways I'll look through and see if I can fix stuff up
2370 09:09 < jtanx> then I'll try and do that start/stop stuf
2371 09:10 < sam_moore> Ok
2372 09:10 < sam_moore> I put in Sensor_Start and Sensor_Stop which might help
2373 09:10 < sam_moore> I thought you might want to pause data collection without actually "stopping" the experiment?
2374 09:11 < jtanx> ok
2375 09:11 < jtanx> that might be a good idea
2376 09:11 < sam_moore> And also it should be fairly easy to implement a Sensor_Load if we want to be able to load previous experiments
2377 09:11 < jtanx> yeah
2378 09:38 < jtanx> those issues with fread
2379 09:38 < jtanx> it could be because you didn't specify the 'b' flag in fopen
2380 09:38 < jtanx> ?
2381 09:39 < jtanx>  // Clear the FILE*s
2382 09:39 < jtanx>  df->read_file = NULL;
2383 09:39 < jtanx>  df->write_file = NULL;
2384 09:39 < jtanx>  fclose(df->write_file);
2385 09:52 < sam_moore> Oh... hurdur
2386 09:52 < sam_moore> Wait how is it working at all
2387 09:52 < sam_moore> The write file is mode "w+" which should make it plain text
2388 09:53 < jtanx> so it's no longer a binary file?
2389 09:53 < jtanx> I think i may not be experiencing the same issues as you just because I'm running everything on single core processors
2390 09:53 < sam_moore> Well... it certainly looks like a binary file when you try and cat it
2391 09:53 < jtanx> ok
2392 09:53 < jtanx> it's probably a good idea to stick to one file pointer and use mutexes
2393 09:53 < sam_moore> Yeah
2394 09:53 < sam_moore> But also make sure that file is binary
2395 09:53 < jtanx> yeah
2396 09:54 < sam_moore> It's probably compiler specific what happens when you use fwrite and fread on a plain text file
2397 09:54 < jtanx> probably
2398 09:54 < sam_moore> But it looks like a binary file to me, so I'm not sure that's related to the problems with fread
2399 09:54 < sam_moore> I can investigate this by changing like 4 characters...
2400 09:55 < jtanx> one thing I did notice on linux
2401 09:55 < jtanx> if it wasn't a binary file you'd have to use fflush to explicitly write out text and have it appear when you used cat
2402 09:56 < jtanx> but overall I think it's not due to it being a binary file or not
2403 09:56 < sam_moore> Yep
2404 09:56 < sam_moore> I just put the second FILE* for read_file back in
2405 09:56 < sam_moore> Made them both binary
2406 09:56 < sam_moore> Still get the "Transport endpoint is not connected" errors
2407 09:57 < sam_moore> So there should be a "b" in the file mode, but that's unrelated to having multiple FILE*
2408 09:57 < jtanx> yep then I think that's due to you running it on a multicore processor
2409 09:57 < jtanx> maybe
2410 09:57 < sam_moore> I think the OS locks around file access are based on PID
2411 09:58 < jtanx> on linux all file locks are advisory only
2412 09:58 < sam_moore> Can
2413 09:58 < sam_moore> Anyway, it's clearly safest to just have one FILE*
2414 09:58 < jtanx> yeah
2415 09:58 < jtanx> I'm changing it now
2416 10:09 < jtanx> oh ffs that's the second time it's crashed simply because I didn't do make clean before make
2417 10:16 < sam_moore> haha
2418 10:17 < sam_moore> Modify the make file to always run make clean?
2419 10:28 < jtanx> haha that's one option
2420 10:28 < jtanx> it's because make doesn't consider changes to the header files
2421 10:28 < jtanx> there's a way to make it detect those, but *effort*
2422 10:40 < sam_moore> Regarding Actuators, I think if we design for a thread to control (one or more) actuators that will make it easy to add more advanced control later
2423 10:42 < sam_moore> eg: The Actuator_Handler just sets some kind of formula or says "Every time sensor 0 is stable for Xs (within a range) change actuator by Y" and the thread watches the sensor data and changes the actuator when necessary
2424 10:43 < sam_moore> You could also add feedback that way too
2425 10:44 < sam_moore> "Set this actuator so that sensor 0 has value X"
2426 10:46 < jtanx> hmm
2427 10:47 < jtanx> about the sensor stuff
2428 10:47 < jtanx> there were a few things I noticed
2429 10:48 < jtanx> the time wrapping 
2430 10:48 < jtanx> could still give a negative start_time or end_time
2431 10:48 < jtanx> if the user specified a very negative start_time/end_time
2432 10:49 < jtanx> (eg specifies a negative time greater than the total running time)
2433 10:49 < sam_moore> Oh yeah
2434 10:49 < jtanx> so in data_printbytimes
2435 10:49 < jtanx> I just clamped it to zero
2436 10:49 < jtanx> instead of asserting
2437 10:49 < sam_moore> Fair enough
2438 10:49 < jtanx> strangely this code seems to work pretty good:
2439 10:49 < jtanx> void Data_PrintByTimes(DataFile * df, double start_time, double end_time, DataFormat format)
2440 10:49 < jtanx> {
2441 10:49 < jtanx>  assert(df != NULL);
2442 10:49 < jtanx>  //Clamp boundaries
2443 10:49 < jtanx>  if (start_time < 0)
2444 10:49 < jtanx>          start_time = 0;
2445 10:50 < jtanx>  if (end_time < 0)
2446 10:50 < jtanx>          end_time = 0;
2447 10:50 < jtanx>  int start_index = 0, end_index = 0;
2448 10:50 < jtanx>  if (start_time < end_time)
2449 10:50 < jtanx>  {
2450 10:50 < jtanx>          start_index = Data_FindByTime(df, start_time, NULL);
2451 10:50 < jtanx>          end_index = Data_FindByTime(df, end_time, NULL);
2452 10:50 < jtanx>  }
2453 10:50 < jtanx>  Data_PrintByIndexes(df, start_index, end_index, format);
2454 10:50 < jtanx> }
2455 10:50 < jtanx> oh but that was the other ting
2456 10:50 < jtanx> it works better if you have exclusive end index/time
2457 10:50 < sam_moore> Ok
2458 10:50 < sam_moore> I have to go now
2459 10:50 < jtanx> ok
2460 10:50 < sam_moore> See you this afternoon if you're still there
2461 10:50 < jtanx> yep see you then
2462 10:51 < jtanx> probably
2463 10:58 -!- jtanx [[email protected]] has quit [Connection reset by peer]
2464 13:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2465 13:44 -!- callum [[email protected]] has joined #mctxuwa_softdev
2466 13:44 < callum> should i just add the sensor threshold values to the sensor struct?
2467 13:47 < jtanx> probably not
2468 13:47 < jtanx> I think you have to create a new struct
2469 13:48 < jtanx> are you at uni?
2470 13:49 < callum> yea. why is a new struct necessary? 
2471 13:49 < jtanx> come to g19
2472 13:49 < jtanx> the bbb is setup too
2473 14:03 -!- callum [[email protected]] has quit [Connection reset by peer]
2474 16:17 < sam_moore> Are you guys still in G19?
2475 16:17 < sam_moore> On my way now
2476 17:30 -!- jtanx [[email protected]] has quit [Ping timeout]
2477 18:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2478 18:42 < jtanx> lol you need to use a transistor to turn on an led from the gpio pins
2479 19:56 < jtanx> ok I think I'll just escape all input parameters from within the request loop
2480 19:56 < jtanx> then at least you're guaranteed that user input won't stuff up anything
2481 19:56 < jtanx> (as in making it generate invalid JSON)
2482 20:53 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2483 --- Day changed Sat Sep 14 2013
2484 09:58 -!- MctxBot [[email protected]] has quit [Ping timeout]
2485 11:08 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2486 11:32 < sam_moore> blergh, too many different versions of OpenCV
2487 11:32 < sam_moore> Also too many different data types
2488 11:33 < sam_moore> "Getting a digital image into numbers can be very handy for your image processing. In this post i will brief just that."
2489 11:34 < sam_moore> Thank god, finally a tutorial that makes sense
2490 11:34 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
2491 11:34 < sam_moore> ... no one else is in the channel
2492 11:34 < sam_moore> :S
2493 11:37 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2494 12:36 < jtanx> on start/stop/pausing an experiment
2495 12:36 < jtanx> currently everything is relative to g_options.start_time
2496 12:42 < sam_moore> Yeah
2497 12:43 < sam_moore> Perhaps make an ExperimentTime function and that leaves us free to change what the time stamps are relative to?
2498 12:43 < sam_moore> Looking into this interferometer stuff...
2499 12:43 < jtanx> ok, maybe as part of the Control_ module then
2500 12:43 < sam_moore> Interesting problem, I think I've worked out an algorithm that isn't too terrible
2501 12:44 < jtanx> yeah?
2502 12:44 < jtanx> how does it work
2503 12:45 < sam_moore> If you have a sinusoidal wave, find the x intercepts, and that lets you calculate the phase and frequency
2504 12:45 < sam_moore> That's the simple version
2505 12:46 < jtanx> haha alright
2506 12:46 < sam_moore> I have 3 pages of notes that I can show Adrian/Adam if I can't get it working
2507 12:46 < jtanx> wow
2508 12:46 < jtanx> nice work
2509 12:47 < sam_moore> Fortran would be good for the array operations
2510 12:47 < sam_moore> If fortran were able to do anything *other* than array operations it would be a nice language...
2511 12:47 < jtanx> have you ever used Fortan before?
2512 12:48 < sam_moore> Yes
2513 12:48 < sam_moore> I'm going to keep it in C though
2514 12:48 < sam_moore> It took long enough to get OpenCV working
2515 12:48 < sam_moore> I'm sure there's some kind of convoluted Fortran library
2516 12:49 < sam_moore> But a seperate fortran program won't talk to our server
2517 12:49 < jtanx> can you compile the code as a library with C interop
2518 12:49 < sam_moore> Erm..
2519 12:49 < sam_moore> Probably more effort than just doing it in C
2520 12:49 < jtanx> probably
2521 12:51 < jtanx> I think a separate mutex is needed around the *_Stop() functions
2522 12:51 < jtanx> because if a client sends in a request
2523 12:51 < sam_moore> Oh, good point
2524 12:52 < jtanx> although that's only going to be a problem if our own software calls the stop function because of the sanity checks
2525 12:52 < sam_moore> If there are 2 requests?
2526 12:52 < sam_moore> No wait, the FCGI stuff is serial
2527 12:52 < jtanx> the request loop is single threaded
2528 12:52 < sam_moore> It has to finish processing one request to respond to the next
2529 12:52 < sam_moore> That's fine
2530 12:56 < sam_moore> Put a mutex in the Sensor struct, use the same one that's already in the Actuator struct, put critical sections around setting the "s->record_data" or "a->activated" variables (or whatever you choose to use as a "is thing running" flag)
2531 12:56 < sam_moore> And check the flag hasn't already been set before doing anything
2532 12:57 < sam_moore> Similar to how the Thread_Running() and Thread_QuitProgram() functions used to work
2533 12:57 < sam_moore> .... Before I deleted them
2534 12:57 < sam_moore> Any thread could call Thread_QuitProgram, and repeated calls would have no effect
2535 13:01 < jtanx> ok I'll try that
2536 13:51 < jtanx> actually, what about this:
2537 13:51 < jtanx> in control.c, it maintains its own mutex
2538 13:51 < jtanx> so
2539 13:52 < jtanx> and it's the only place where Sensor_Start/Stop Actuator_Start/Stop is called
2540 13:53 < jtanx> You then have Control_Lock/Unlock that's placed around the responses in the handler functions
2541 13:53 < jtanx> those functions internally lock/unlock the mutex held in control.c
2542 13:53 < jtanx> ah stuff it
2543 13:53 < jtanx> I'll commit it to my git repo
2544 13:54 < jtanx> I still don't know how the pause functionality should be done though
2545 13:54 < jtanx> especially with the time discontinuities
2546 14:01 < jtanx> oh yeah, just a reminder that you have to be careful using FCGI_LONG_T vs FCGI_INT_T
2547 14:02 < jtanx> if your variable is of type int but you give FCGI_LONG_T, and where sizeof(int) != sizeof(long) then there could be a buffer overflow
2548 14:13 < sam_moore> Right
2549 14:14 < sam_moore> If you want to commit to the main repo you can use a new branch
2550 14:14 < sam_moore> Having a single mutex in control.c instead of one per sensor/actuator is probably better
2551 14:15 < sam_moore> With the pause functionality... I think if you just don't call Data_Close() (and don't call Data_Open on resuming) but otherwise stop the threads running Sensor_Loop in the same way
2552 14:15 < sam_moore> That should do most of it
2553 14:16 < sam_moore> Don't reset the experiment start time
2554 14:17 < sam_moore> Perhaps the experiment start time needs to be stored somewhere though
2555 14:18 < sam_moore> Anyway, I'll let you solve the problem :P
2556 14:48 < jtanx> ._.
2557 15:45 < jtanx> well I think I got something semi-working
2558 15:45 < jtanx> it involved adding on Sensor_PauseAll/ResumeAll + Acuator_PauseAll/ResmueAll (plus the individual Pause/Resume) functions
2559 15:46 < sam_moore> Cool
2560 15:46 < sam_moore> I think I'm starting to get my head around OpenCV
2561 15:46 < sam_moore> The documentation for it is a bit crap
2562 15:46 < jtanx> oh don't get me started on opencv documentation
2563 15:47 < jtanx> yesterday it took me and callum around 30  mins to figure out that CvMat structure
2564 15:47 < sam_moore> Haha
2565 15:47 < sam_moore> It probably took me a bit longer :S
2566 15:47 < jtanx> the problem is that most of it's geared towards c++ usage
2567 15:49 < jtanx> back on that control stuff, basically those Sensor/Actuator_[Start|Stop|Pause|Resume] functions can only be called via the Control_[Start|Stop|Pause|Resume] functions
2568 15:50 < jtanx> partly because of threading issues but also because it's the only place where the current state is currently kept track of
2569 15:51 < jtanx> (e.g if you call Sensor_Start twice then...
2570 15:53 < sam_moore> Seems sensible
2571 15:53 < jtanx> anyway, I'm taking a break from this stuff for a while
2572 15:53 < sam_moore> Yeah, fair enough
2573 15:54 < jtanx> If you want to see what I've done so far, it's on my git repo (haven't added comments yet)
2574 15:54 < sam_moore> Cool
2575 16:50 < sam_moore> The IplImage vs CvMat conversion is dumb
2576 16:50 < sam_moore> In fact I don't think you even need to do it?
2577 16:51 < sam_moore> Well at least to display an image you can just pass a CvMat
2578 16:51 < sam_moore> Maybe you still need the IplImage to capture from a camera
2579 16:51 < sam_moore> I worked out how to convert from IplImage to CvMat anyway
2580 16:53 < sam_moore> Other than that, OpenCV doesn't actually seem horrible to use
2581 16:53 < sam_moore> Just... contradictory documentation
2582 16:55 < sam_moore> Anyway... I've created a moving sinusoidal image!
2583 16:56 < sam_moore> Now to work out why the algorithm keeps returning -nan :S
2584 16:56 < sam_moore> Also for some reason the image is blue instead of red
2585 16:56 < sam_moore> But whatever
2586 16:57 < jtanx> :S
2587 16:57 < jtanx> BGR vs RGB?
2588 17:02 < sam_moore> Looks like it
2589 17:03 < sam_moore> Doing this with an actual camera is going to suck
2590 17:04 < sam_moore> See, I've worked out an algorithm to cope with changing background light conditions
2591 17:04 < sam_moore> Because differentiating a sinusoid gives you another sinusoid with the same phase (offset by pi/2)
2592 17:05 < sam_moore> Buut... differentiating with finite differences adds more noise
2593 17:05 < sam_moore> Or rather it makes the noise more pronounced
2594 17:07 < sam_moore> Hopefully sensors is considering this
2595 17:07 < sam_moore> If they want to shoot a laser into a camera, they should really do it in a way that keeps out background light
2596 17:07 < sam_moore> Buuut
2597 17:07 < sam_moore> I think they mentioned using one camera to do both the interferometer and look at the can
2598 17:07 < sam_moore> :S
2599 17:08 < sam_moore> Oh well, the optics is their problem
2600 17:09 < sam_moore> I suppose I will prepare a report or something about the algorithm and what conditions the image needs to satisfy
2601 17:12 < jtanx> um
2602 17:12 < jtanx> there's going to be two cameras
2603 17:12 < jtanx> because it was too much hassle moving it
2604 17:12 < sam_moore> Yes... but one was meant to be looking at each can?
2605 17:13 < jtanx> oh
2606 17:13 < jtanx> hmm
2607 17:13 < sam_moore> We should ask them
2608 17:13 < jtanx> I just thought that one would be for the interferometer (no need to look at can) and the other would be for the can to be blown up
2609 17:13 < sam_moore> Probably
2610 17:15 < jtanx> but I was thinking for the one to be blown up
2611 17:16 < jtanx> you could possibly just stream it using something like ffserver
2612 17:16 < jtanx> instead of passing it through opencv
2613 17:16 < sam_moore> Yeah, that seems like it's probably easier
2614 17:23 -!- jtanx [[email protected]] has quit ["my antivirus is pestering me to restart"]
2615 17:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2616 18:19 < sam_moore> So... when you take an image with a camera the pixels are stored as rgb with 0->255 values
2617 18:20 < sam_moore> You can convert the IplImage to a CvMat and it keeps the values ordered as rgb with 0->255 values
2618 18:20 < sam_moore> And then...
2619 18:20 < sam_moore> If you try and display it...
2620 18:20 < sam_moore> The display function treats it as having values in bgr order with 0->1 values
2621 18:20 < sam_moore> -_-
2622 18:21 < sam_moore> (So unless you manually adjust all the values you'll just get a white picture in the display)
2623 18:54 < jtanx> hahaha
2624 18:54 < jtanx> what
2625 18:56 < jtanx> for cvShowImage:
2626 18:56 < jtanx>         If the image is 8-bit unsigned, it is displayed as is.
2627 18:56 < jtanx>         If the image is 16-bit unsigned or 32-bit integer, the pixels are divided by 256. That is, the value range [0,255*256] is mapped to [0,255].
2628 18:56 < jtanx>         If the image is 32-bit floating-point, the pixel values are multiplied by 255. That is, the value range [0,1] is mapped to [0,255].
2629 18:57 < jtanx> so it's treating it as 32-bit floating point?
2630 19:49 -!- jtanx [[email protected]] has quit [Ping timeout]
2631 19:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2632 20:41 < sam_moore> I think it's because of how I converted the IplImage to a CvMat
2633 20:42 < sam_moore> My algorithm is almost working
2634 20:43 < sam_moore> The fact that angles wrap around every 2*pi is giving me a headache though
2635 20:43 < sam_moore> This is pretty fun
2636 20:45 < sam_moore> Hopefully I can do Computer Vision as an optional, I think its in the list
2637 20:45 < sam_moore> Maybe I shouldn't make all my optionals CS units, but meh
2638 21:20 < jtanx> :P
2639 21:20 < jtanx> the computer vision unit sounds interesting, but a lot of maths/theory involved
2640 22:02 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2641 --- Day changed Sun Sep 15 2013
2642 09:13 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2643 11:02 < sam_moore> I'm really glad I put the IRC logs under git
2644 11:02 < sam_moore> It's very helpful for keeping my diary up to date
2645 11:40 < jtanx> hehe
2646 11:40 < jtanx> I'm gladful for git
2647 11:48 < jtanx> about the bbb
2648 11:48 < jtanx> it's probably best to just install debian to the internal memory
2649 11:54 < jtanx> on the controls
2650 11:54 < jtanx> maybe we can have the following states: start/pause/resume/stop/close
2651 11:56 < jtanx> actually, maybe just start/pause/resume/close
2652 11:56 < jtanx> when an 'emergency stop' due to the sanity checks occurs
2653 11:57 < jtanx> actually, start/pause/resume/close/emergency
2654 11:57 < jtanx> start/pause/resume/close can only be initiated by the client
2655 11:58 < jtanx> emergency can be initiated by client/server
2656 11:58 < jtanx> in emergency, actuators are set as necessary then deactivated
2657 11:58 < jtanx> but importantly, the data files remain open, which hopefully removes the need for mutexes
2658 12:26 < sam_moore> That seems sensible
2659 13:20 < sam_moore> Hey
2660 13:20 < sam_moore> It's actually quite simple to stream an image through FastCGI
2661 13:21 < jtanx> yeah
2662 13:21 < jtanx> you just fwrite the image buffer
2663 13:21 < sam_moore> Yep
2664 13:21 < jtanx> I had some test code for that but could never test it
2665 13:22 < jtanx> no webcam
2666 13:22 < sam_moore> Ah, damn
2667 13:22 < sam_moore> I've written some code, it works pretty brilliantly
2668 13:22 < jtanx> nice
2669 13:22 < jtanx> this control code is really annoying me
2670 13:23 < jtanx> just all the considerations of if you need a mutex here or not and 'what happens if...'
2671 13:23 < sam_moore> Ah, sorry to hear that
2672 13:23 < jtanx> yeah nah its ok
2673 13:24 < jtanx> but that interferometer stuff you did looks really cool
2674 13:26 < sam_moore> Yeah, it worked surprisingly well
2675 13:26 < sam_moore> It can cope with a fair bit of background light, even without all the improvements I was thinking about
2676 13:27 < sam_moore> If I add 2 or 3 more columns to scan, and use the fact that we actually know the spatial frequency to eliminate nodes that are too close together
2677 13:27 < sam_moore> It should be pretty good
2678 13:27 < sam_moore> I'm not sure what the laser intensity will be, but the generated image looks similar to ones you can find on the internet
2679 13:28 < sam_moore> One possible problem is if the mirrors aren't flat enough
2680 13:28 < sam_moore> But hopefully it won't be a big issue (since they've pretty much just specified an expensive pre-built kit which presumably has flat mirrors)
2681 13:29 < jtanx> yeah
2682 13:30 < jtanx> here's to hoping 'it just works'
2683 13:30 < sam_moore> Yep :P
2684 13:31 < sam_moore> Got to go, bye
2685 13:32 < jtanx> ok cya
2686 15:50 -!- jtanx [[email protected]] has quit [Ping timeout]
2687 15:56 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
2688 15:56 -!- jtanx_ is now known as jtanx
2689 21:48 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2690 --- Day changed Mon Sep 16 2013
2691 07:28 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2692 08:27 -!- jtanx [[email protected]] has quit [Ping timeout]
2693 12:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2694 16:05 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
2695 16:05 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2696 16:10 -!- jtanx [[email protected]] has quit [Ping timeout]
2697 19:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2698 19:44 < jtanx> no mctxbot while I work on my f# project
2699 20:00 -!- MctxBot [[email protected]] has quit [Ping timeout]
2700 21:26 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2701 22:58 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2702 --- Day changed Tue Sep 17 2013
2703 08:14 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2704 09:50 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2705 15:34 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2706 15:34 < jtanx> to run the software not as root, we need to at least add it to the 'video' group so it can access the webcam
2707 15:34 < jtanx> not sure about the sensors
2708 15:34 < jtanx> eg sudo usermod -a -G video debian
2709 15:38 < sam_moore> Ah, cool
2710 15:39 < sam_moore> I think I worked out how to get around the camera crashing without killing the rest of the program, won't implement it for a while though
2711 15:40 -!- MctxBot [[email protected]] has quit [EOF From client]
2712 15:43 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
2713 15:48 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2714 15:53 -!- jtanx [[email protected]] has quit [Ping timeout]
2715 15:57 -!- jtanx_ is now known as jtanx
2716 16:41 -!- jtanx [[email protected]] has quit [Ping timeout]
2717 16:46 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
2718 16:46 -!- jtanx_ is now known as jtanx
2719 18:02 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2720 18:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2721 19:31 -!- MctxBot [[email protected]] has quit [Ping timeout]
2722 22:38 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2723 22:49 -!- jtanx [[email protected]] has quit [Ping timeout]
2724 23:17 -!- Callum [[email protected]] has joined #mctxuwa_softdev
2725 23:18 < Callum> hey
2726 23:23 < sam_moore> Hi
2727 23:24 < Callum> do you know how to do the second question of that assignment?
2728 23:24 < Callum> https://docs.google.com/file/d/0B241H5liqVlnbHZETXRZX1Mwd1k/edit?usp=sharing
2729 23:25 < Callum> rather remember
2730 23:35 < sam_moore> Well, you can eliminate any epsilon^2 when you substitute those formulae for v into the formula for gamma
2731 23:35 < sam_moore> Then it has a really simple taylor expansion
2732 23:35 < Callum> i might have to hunt you down tomorrow to show me. or maybe il be able to think straight tomorrow.
2733 23:38 < sam_moore> You can express one of the epsilons in terms of the other one after that
2734 23:40 < sam_moore> I'm pretty busy tomorrow
2735 23:42 < Callum> mhmm. so no free time at all? coz im fairly free
2736 23:49 < sam_moore> Not from 8:00am until 5:00pm
2737 23:49 < Callum> ohwow. you are busy
2738 23:49 < Callum> im still unsure what im meant to be applyign the taylor expansion to
2739 23:53 < sam_moore> Substitute in the suggested formulae to gamma, simplify it, then apply a taylor expansion
2740 23:53 < sam_moore> Anyway, goodnight, good luck
2741 23:53 < Callum> night
2742 --- Day changed Wed Sep 18 2013
2743 00:07 -!- Callum [[email protected]] has quit [EOF From client]
2744 07:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2745 09:11 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
2746 18:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2747 19:04 -!- MctxBot [[email protected]] has quit [Ping timeout]
2748 21:03 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
2749 21:39 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2750 --- Day changed Thu Sep 19 2013
2751 16:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2752 16:08 < jtanx> one thing I forgot to mention - the latest version on git uses syslog
2753 16:08 < jtanx> if you copy the config file (server-configs/rsyslog.d/* ??) to /etc/
2754 16:09 < jtanx> it will log to /var/log/mctx[something I can't remember].log
2755 16:10 < jtanx> i'm pretty sure you can also create a log file specifically for warning level and above (so it logs in three places, stderr, the normal log, and a special 'error' log), but I haven't set this up yet
2756 18:15 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
2757 18:17 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
2758 18:17 < jtanx_> :0
2759 18:22 < sam_moore> ?
2760 18:30 -!- MctxBot [[email protected]] has quit [Ping timeout]
2761 18:31 -!- jtanx [[email protected]] has quit [Ping timeout]
2762 18:50 -!- jtanx_ is now known as jtanx
2763 19:11 -!- jtanx [[email protected]] has quit [Ping timeout]
2764 19:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2765 19:52 -!- MctxBot_ is now known as MctxBot
2766 20:24 < jtanx> I got the camera image to be updated in javascript instead: http://mctx.us.to:8080/test/
2767 20:25 < jtanx> right now it's updated around every ~400ms because my webcam is running through a usb1.1 link which seriously limits how fast it can update
2768 20:36 < jtanx> (its running on a pentium 3 computer)
2769 21:35 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
2770 --- Day changed Fri Sep 20 2013
2771 15:38 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2772 15:53 -!- MctxBot [[email protected]] has quit [Ping timeout]
2773 18:02 < jtanx> this seems like an interesting option, at least for the cam that just shows the can explode:http://sourceforge.net/apps/mediawiki/mjpg-streamer/index.php?title=Main_Page
2774 18:51 < sam_moore> Cool
2775 18:51 < sam_moore> It, ah
2776 18:52 < sam_moore> Looks like we might have to recompile the kernel to get PWM working
2777 18:52 < sam_moore> Hooray
2778 18:52 < sam_moore> Kernel compiling
2779 18:52 < sam_moore> What could possibly go wrong?
2780 19:02 < jtanx> really??
2781 19:02 < jtanx> why....
2782 19:03 < jtanx> no am33xx_pwm module?
2783 19:04 < sam_moore> Not that I can tell
2784 19:05 < jtanx> well crap
2785 19:06 < sam_moore> Well... surely I can find a precompiled kernel somewhere
2786 19:06 < jtanx> it seems that stuff for the BBB is at a really premature stage
2787 19:07 < sam_moore> Yeah, RPi is much nicer
2788 19:07 < jtanx> the BBB is just too new..
2789 19:07 < sam_moore> What's the point of having fancy things like ADC and PWM...
2790 19:07 < sam_moore> If you can't actually use them without jumping through hoops
2791 19:07 < jtanx> hahaha
2792 19:07 < jtanx> were you referencing this, when you said we might have to recompile the kernel? https://groups.google.com/d/msg/beagleboard/wjbOVE6ItNg/AGYVRhYbTX8J
2793 19:08 < sam_moore> Yeah
2794 19:08 < sam_moore> ...
2795 19:08 < sam_moore> I wonder if I can take the kernel used by Angstrom and stick it in /boot
2796 19:08 < sam_moore> on the SD card
2797 19:09 < jtanx> ._.
2798 19:10 < jtanx> what about kernels from here
2799 19:10 < jtanx> http://rcn-ee.net/deb/precise-armhf/
2800 19:10 < jtanx> sorry
2801 19:10 < jtanx> http://rcn-ee.net/deb/wheezy-armhf/
2802 19:11 < jtanx> what's it currently running
2803 19:12 < sam_moore> 3.8.13-bone20
2804 19:13 < sam_moore> Try 3.8.13-bone28 ?
2805 19:15 < jtanx> what about v3.8.9-bone15
2806 19:15 < jtanx> oh wait
2807 19:15 < jtanx> ~.~
2808 19:15 < sam_moore> I wonder why the BBB developers didn't go with debian...
2809 19:15 < jtanx> v3.11.0-bone5
2810 19:15 < jtanx> yeah
2811 19:15 < jtanx> why angstrom, of all things
2812 19:15 < sam_moore> Is angstrom used anywhere else?
2813 19:16 < jtanx> dunno
2814 19:16 < sam_moore> Other embedded devices, heh
2815 19:16 < sam_moore> Everyone just has to use their own distro :P
2816 19:17 < sam_moore> I didn't see the .11 kernels, I'll try the latest one
2817 19:17 < jtanx> want to try the rc version? lol
2818 19:18 < jtanx> oh the rc versions are older than .11
2819 19:19 < jtanx> how does it work?
2820 19:19 < jtanx> do you just download from http://rcn-ee.net/deb/wheezy-armhf/v3.11.0-bone5/
2821 19:19 < jtanx> the .sh script and run it from the BBB?
2822 19:24 < sam_moore> I think so
2823 19:25 < sam_moore> Well... here goes nothing
2824 19:26 < sam_moore> Hopefully between 3.8 and 3.11 they actually enabled PWM by default...
2825 19:27 < sam_moore> It looks like install-me.sh downloads all the .deb files appropriately
2826 19:29 < sam_moore> It's creating files like: /lib/firmware/bone_pwm_P8_36-00
2827 19:29 < sam_moore> Which looks promising
2828 19:29 < sam_moore> Snoopy is not yet on fire
2829 19:29 < sam_moore> Which is promising
2830 19:29 < sam_moore> Rebooting and praying
2831 19:31 < sam_moore> And... it booted into 3.8.13-bone20 -_-
2832 19:31 < sam_moore> Tempted to just symlink that filename to the new kernel
2833 19:34 < sam_moore> The new kernel exists in /boot, but obviously there's some boot config that needs to get set
2834 19:39 < sam_moore> Ok, screw this, I'm making a symlink just to see if it works
2835 19:40 < jtanx> lol
2836 19:41 < jtanx> no grub
2837 19:43 < jtanx> did update-initramfs run?
2838 19:46 < jtanx> or maybe we need mkimage
2839 19:47 < jtanx> yeah probably need mkimage
2840 19:50 < sam_moore> Um, zImage is a symlink to the kernel
2841 19:50 < sam_moore> But regardless, the new one won't boot
2842 19:50 < sam_moore> Such a pain
2843 19:50 < sam_moore> I wonder if we can just toggle the GPIO pin fast enough to implement PWM
2844 19:56 < sam_moore> Using a decent oscilloscope, I read a 6us period when switching GPIO1_28 on/off as fast as possible
2845 19:59 < sam_moore> That
2846 19:59 < sam_moore> s like 166KHz
2847 19:59 < sam_moore> Heh
2848 19:59 < sam_moore> Maybe the sources you found were closing the file and reopening it?
2849 20:01 < sam_moore> Yeah, wow
2850 20:02 < sam_moore> Using fopen, fprintf and fclose each time takes the period to 224us
2851 20:02 < sam_moore> Or 4KHz
2852 20:03 < sam_moore> Also for future reference, that CRO in G19 is definitely broken; it's always a lovely square wave on the modern oscilloscope I'm testing with now
2853 20:12 < jtanx> haha ok
2854 20:13 < jtanx> but without kernel support your pwm signal won't be very accurate
2855 20:13 < sam_moore> Yeah, I suppose
2856 20:13 < jtanx> how come the new kernel won't boot?
2857 20:14 < sam_moore> No idea
2858 20:14 < jtanx> Hmm
2859 20:14 < jtanx> this lack of documentation on how you do such procedures is pretty crap
2860 20:15 < sam_moore> Yeah, kernel developers aren't great on documentation
2861 20:15 < jtanx> is the mkimage package present?
2862 20:15 < jtanx> if not, install it and try running the install-me script again
2863 20:16 < jtanx> from this: http://www.jeremycole.com/blog/2011/03/09/beagleboard-upgrading-from-debian-5-to-debian-6/
2864 20:16 < jtanx> it should be just running that install script and rebooting
2865 20:16 < sam_moore> Alright, uboot-mkimage I presume?
2866 20:16 < jtanx> i guess
2867 20:17 < jtanx> and update-initramfs?
2868 20:18 < jtanx> (just looking at what the install-me.sh script uses)
2869 20:18 < sam_moore> Oh, does the script not fail if packages it needs don't exist...
2870 20:18 < sam_moore> -_-
2871 20:19 < jtanx> a quick scan says nup
2872 20:24 < sam_moore> Already had initramfs-tools but not mkimage, so I'll try again
2873 20:27 < sam_moore> I should probably have focused on the ADC reading before PWM
2874 20:27 < sam_moore> We're definitely going to get asked about aliasing again
2875 20:28 < jtanx> urgh yeah
2876 20:28 < sam_moore> I don't have a signal generator here though
2877 20:28 < jtanx> this BBB has definitely not been designed with 'plug n play' in mind
2878 20:28 < sam_moore> Mmm
2879 20:29 < sam_moore> The Angstrom image would work for this stuff, but obviously has limitations in terms of the webserver stuff
2880 20:29 < sam_moore> But even with Angstrom you still have to go through a similar convoluted process to control pins
2881 20:30 < sam_moore> From what I can tell there are two ways to do it
2882 20:30 < sam_moore> SYSFS, which I can't find much documentation on
2883 20:30 < sam_moore> Which is the /sys/class/gpio/ stuff
2884 20:30 < sam_moore> Which actually seems more intuitive than the other way
2885 20:31 < sam_moore> That involves echoing a bunch of cruft to /sys/devices/cape-manager/slots/ or something similar
2886 20:31 < jtanx> hmm
2887 20:32 < sam_moore> There is a /sys/class/pwm
2888 20:32 < sam_moore> But unfortunately whatever you export it complains about
2889 20:32 < sam_moore> Probably because the kernel wasn't compiled with it enabled
2890 20:32 < jtanx> is this with the old kernel?
2891 20:32 < sam_moore> Yeah
2892 20:33 < sam_moore> Hangon, the new one's probably finished building by now
2893 20:34 < jtanx> we don't know if the new one has been compiled with pwm support though
2894 20:34 < sam_moore> Yeah
2895 20:36 < sam_moore> The diff between the config options for the kernels shows that the old one has a comment "CONFIG_EHRPWM_TEST is not set" and the newer one has no reference to it
2896 20:37 < sam_moore> ...
2897 20:37 < sam_moore> Someone at some point
2898 20:37 < sam_moore> Has realised that PWM was not enabled
2899 20:37 < sam_moore> And commented that it isn't enabled
2900 20:37 < sam_moore> WHY THE HELL DIDN'T THEY JUST ENABLE IT
2901 20:37 < jtanx> :P
2902 20:37 < sam_moore> Anyway it still booted off the old kernel
2903 20:37 < sam_moore> Dinner time
2904 20:38 < jtanx> ok
2905 20:57 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
2906 21:15 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
2907 21:15 < sam_moore> Looks promising
2908 21:16 < sam_moore> Hmm...
2909 21:17 < sam_moore> I'll try using 3.8 but building with the PWM
2910 21:18 < jtanx> building from source - fun fun :P
2911 21:19 < sam_moore> Well in theory I just change a config option
2912 21:19 < jtanx> yeah
2913 21:19 < sam_moore> When that doesn't work and I have to modify the source, that's when the fun begins
2914 21:19 < jtanx> let's just hope it works
2915 21:19 < sam_moore> Yeah, if it doesn't we're (beagle) boned
2916 21:19 < jtanx> oh while you're at it, figure out how to enable the ethernet-over-usb feature
2917 21:19 < sam_moore> Haha
2918 21:20 < jtanx> loljk
2919 21:25 < sam_moore> Hmmm... compiling a kernel is going to take a while
2920 21:26 < sam_moore> Ergh, why am I running it on this Pentium D
2921 21:30 < sam_moore> Hmmm, more troubling... why does a debian wheezy server have OpenSUSE sources in sources.list
2922 21:30 < sam_moore> Oh well, not my problem
2923 21:33 < jtanx> heh
2924 21:33 < sam_moore> How the hell are we going to explain this in the progress report...
2925 21:34 < sam_moore> Also, I didn't fully understand, why can't you use the same image for multiple BBB?
2926 21:34 < sam_moore> Are we going to have to do this all again for the other BBB?
2927 21:34 < sam_moore> Spike I mean
2928 21:37 < jtanx> no idea
2929 21:38 < jtanx> without some sort of debugging cable to see what happens when it boots, who knows
2930 21:38 < sam_moore> :S
2931 21:39 < sam_moore> I love how git gets to the head of the branch
2932 21:39 < sam_moore> By starting at the initial commit
2933 21:39 < sam_moore> And going through every commit and changing the file
2934 21:42 < sam_moore> It hasn't started building yet
2935 21:42 < sam_moore> And the way you customise the build...
2936 21:42 < sam_moore> Is to build it with the defaults, so that the options file exists, then change the options, then build it again -_-
2937 21:43 < jtanx> ಠ ಠ
2938 21:43 < sam_moore> Oh well, I have to go home, I'll try finish this tomorrow
2939 21:43 < sam_moore> Bye
2940 21:43 < jtanx> ok
2941 21:43 < jtanx> bye
2942 23:20 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
2943 --- Day changed Sat Sep 21 2013
2944 08:42 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2945 11:23 < sam_moore> http://hipstercircuits.com/enable-pwm-on-beaglebone-with-device-tree-overlays/
2946 11:23 < sam_moore> So... according to this I should add pwm_test as a kernel module
2947 11:24 < sam_moore> "This is it. It is now three o’clock in the morning and I have not slept or eaten in two days. My neck is sore, my ass has fallen asleep and my organs are screaming “slow down, man”. I no longer see [CC]s, [LD]s and [AS]s, I only see blondes, brunettes and redheads flashing before my eyes. With my last ounce of energy I barely manage to type in “reboot” as my face hits the keyboard. And that is when it happens.."
2948 11:25 < sam_moore> Ummm
2949 11:25 < sam_moore> It's awesome that this guy has solved the problem (I think)
2950 11:26 < sam_moore> But a bit depressing that it still isn't in the official kernel
2951 11:29 < sam_moore> I think most people just give up and use Angstrom, which is tempting
2952 11:30 < sam_moore> I still have that HTTP server code... :P
2953 11:45 < sam_moore> Looks like Robert C Nelson's 3.8 kernel does have a pwm_test module
2954 11:45 < sam_moore> Maybe the image you used just had an out of date kernel?
2955 11:45 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
2956 11:51 < jtanx> hmm
2957 11:51 < jtanx> no idea
2958 11:51 < jtanx> it was made in july I think and it uses those rcn kernels
2959 11:51 < jtanx> We could always use lighttp
2960 11:51 < jtanx> lighttpd on angstrom if necessary
2961 11:52 < jtanx> lighttpd and install mod_fastcgi
2962 11:55 < jtanx> ok so the image uses 3.8.13-bone20, so maybe it wasn't enabled in that version, but it now is in 3.8.13-bone28?
2963 12:02 < sam_moore> I've just built 3.8.13-bone28 and the module pwm_test exists
2964 12:03 < sam_moore> ... I also copied the code from that guy's blog as pwm_test2 just in case :P
2965 12:03 < sam_moore> I'll have to test it later, but at least we have the kernel module
2966 12:08 < jtanx> nice
2967 12:39 < jtanx> ohhhhh I know why it didn't work from one bbb to the next, using the same image
2968 12:39 < jtanx> When you boot for the first time, it assigns the ethernet port eth0
2969 12:39 < jtanx> when you then take it out and boot it on a different BBB
2970 12:40 < jtanx> because the ethernet device has a different id, it gets assigned to say eth1
2971 12:40 < jtanx> and because you don't have any config for eth1 in your network config, there's no internet access
2972 12:40 < jtanx> http://www.eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-Networking:UsingasharedSDcardwithMultipleBeagleBone
2973 12:41 < jtanx> should fix that
2974 13:21 -!- jtanx [[email protected]] has left #mctxuwa_softdev []
2975 13:21 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
2976 15:10 < jtanx> Eh, you know what I'll just stop the threads when you want to pause it
2977 15:10 < jtanx> instead of conditionals
2978 15:11 < jtanx> it's not like you're pausing the experiment that often
2979 15:18 < sam_moore> That's fine
2980 15:19 < sam_moore> The conditional approach is only really necessary if you're constantly pausing the threads
2981 15:19 < sam_moore> I used it for an nbody simulator, so the computation of force and position was split up between threads
2982 15:19 < sam_moore> It's really slow if you have to stop and then recreate the threads on every step
2983 15:22 < sam_moore> Although still actually faster than the single threaded program
2984 15:22 < sam_moore> Well, depending on how many objects you simulated
2985 15:23 < sam_moore> Anyway, just stop the threads, it's simpler to code and the performance effect in our case is probably negligable
2986 15:30 < jtanx> yeah
2987 15:30 < jtanx> say you had an actuator that was being controlled at that instant when an 'emergency stop' was issued
2988 15:31 < jtanx> since an 'emergency stop' is the same as just pausing (eg stopping the thread but keep DataFile open)
2989 15:31 < jtanx> you'd have to wait for that action to be completed before the 'emergency stop' would be propagated
2990 15:34 < jtanx> welp I guess that's why there's hardware safety interlocks
2991 15:38 < jtanx> Also, technically wouldn't it be possible to try to set the actuator value before the current value has been set
2992 15:38 < jtanx> Since there's no queue
2993 15:39 < jtanx> a->control could be overwritten by a new request as Actuator_SetValue operates
2994 16:12 < sam_moore> We want that right?
2995 16:13 < sam_moore> I'll look at it later if I get time
2996 16:14 < jtanx> I don't know if we want that or not
2997 16:15 < jtanx> wait want as in the current behaviour or the behaviour with a queue?
2998 16:16 < sam_moore> The current behaviour
2999 16:16 < sam_moore> I don't think you need a queue
3000 16:16 < sam_moore> You can extend the critical section in Actuator_Loop to stop the current control getting overwritten
3001 16:17 < sam_moore> Move the pthread_mutex_unlock on line 121 to below line 127 (Actuator_SetValue)
3002 16:17 < sam_moore> That way if Actuator_SetControl is called before the value has been successfully set, it will just wait
3003 16:17 < sam_moore> Mutexes actually implement a queue
3004 16:18 < sam_moore> If one thread has a lock on the mutex, subsequent threads that try to access the mutex will queue up; whenever the mutex is unlocked the next thread (if any) which was waiting will get it
3005 16:18 < jtanx> ok
3006 16:23 < jtanx> I'll leave it as is for now
3007 16:23 < sam_moore> Sure
3008 16:49 < sam_moore> PWM working
3009 16:49 < jtanx> nice
3010 16:50 < jtanx> I still don't really understand - did you compile the kernel from scratch
3011 16:50 < jtanx> or did you figure out how to use the install-me.sh script
3012 16:50 < sam_moore> I did, but I didn't need to modify it
3013 16:50 < jtanx> huh
3014 16:50 < jtanx> ok
3015 16:51 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
3016 16:52 < jtanx> so if we do this: http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone
3017 16:52 < jtanx> We should be able to just copy our image
3018 16:52 < jtanx> and stick it on the electronics' BBB
3019 16:53 < sam_moore> Sounds good
3020 16:53 < sam_moore> I'm glad that worked
3021 16:53 < jtanx> yeah
3022 16:54 < jtanx> I wonder if it also enabled the usb0 stuff (ethernet over usb)
3023 16:58 < sam_moore> PWM appears to have picosecond resolution? Or at least the arguments are in ps
3024 17:02 < jtanx> oO
3025 17:11 < sam_moore> ADC can sample at ~4KHz
3026 17:11 < sam_moore> But... that's using bash
3027 17:11 < sam_moore> It will probably be massively fast when done in C
3028 17:11 < jtanx> um
3029 17:11 < jtanx> is there any need to have it sample at a consistent rate
3030 17:11 < jtanx> as in, with threads there's no guarantee
3031 17:12 < jtanx> of a consistent sampling rate
3032 17:12 < sam_moore> Yes, you're right
3033 17:13 < sam_moore> I don't think we can achieve a consistent sampling rate, but I don't think it's critical that we do
3034 17:14 < sam_moore> As soon as we make our software run in an operating system with a kernel and other processes that can run as well, it gets pretty unfeasable to have a constant sample rate
3035 17:14 < sam_moore> We can have it constant to within an uncertainty I guess
3036 17:15 < jtanx> yeah, true
3037 17:18 < sam_moore> If you wanted a really high constant sample rate (say much faster than 1us which is probably the best case we could get) you'd have to use a more low level embedded device
3038 17:18 < sam_moore> Well I guess you could compile your own kernel for the BBB
3039 17:19 < sam_moore> But either way you'd have to physically run the webserver/GUI interface stuff on a seperate device
3040 17:19 < sam_moore> At this stage my feeling is what we have is good enough given the complexity of all the requirements we were given
3041 17:23 < jtanx> yeah
3042 17:25 < sam_moore> Hmm, I can set some GPIO pins to toggle whenever Sensor_Read is called and get an idea of sample rates and to what degree of accuracy we can quote the time stamps
3043 17:26 < sam_moore> I think I'll write some pin control code
3044 17:26 < sam_moore> I don't trust any of these custom libraries
3045 17:29 < jtanx> custom libraries?
3046 17:36 < sam_moore> Well they aren't really libraries
3047 17:36 < sam_moore> http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO#Example_of_GPIO_access_from_within_a_C_program
3048 17:37 < sam_moore> Eg: That one has an fopen and fclose each time the value is changed
3049 17:38 < sam_moore> I could google until I find someone that has already written a C library, but chances are it will be slow or broken
3050 17:38 < sam_moore> Since I've worked out how to control the pins I may as well just write the C code to do it
3051 17:39 < jtanx> yep
3052 17:49 < sam_moore> I wonder if I can do this with a macro...
3053 18:30 < sam_moore> Ergh, screw that
3054 18:31 < sam_moore> Ok, I'm going to implement things like: GPIO/ADC/PWM_Export/Unexport to initialise or deinitialise all pins
3055 18:31 < jtanx> Ok
3056 18:31 < jtanx> too much effort with macros?
3057 18:31 < sam_moore> Yeah, 
3058 18:32 < sam_moore> I was thinking of having something like "GPIOX_Set()" instead of GPIO_Set(int x)"
3059 18:32 < sam_moore> But that's probably not as nice as I thought it was
3060 18:32 < sam_moore> Anyway, there's an enum in the header file that contains the id of all pins used
3061 18:32 < sam_moore> The implementation defines some structs that wrap around the file descriptors
3062 18:33 < sam_moore> But to use the module you just give it an ID as defined in the enums
3063 18:33 < jtanx> Makes sense
3064 18:33 < jtanx> designing the gui is actually not too bad
3065 18:33 < sam_moore> That's good
3066 18:34 < jtanx> looks ok in ie8 too
3067 18:34 < sam_moore> Nice
3068 18:35 < jtanx> gotta go, dinner
3069 18:35 < sam_moore> Ok
3070 18:35 < sam_moore> Hmm, it would be nice if C had value checking on enums
3071 18:35 < sam_moore> You can define a function that takes an enum type as an argument
3072 18:36 < sam_moore> But people can still just pass any old integer
3073 18:36 < sam_moore> As far as I know
3074 18:36 < sam_moore> eg: typedef enum {FIRST=1, SECOND=10, THIRD=100} EnumType
3075 18:36 < sam_moore> void Foo(EnumType e);
3076 18:37 < sam_moore> If you go Foo(2) it won't complain
3077 18:38 < sam_moore> Annoying
3078 18:38 < sam_moore> That seems like something the compiler would be able to pick up
3079 19:31 < sam_moore> Ergh, I'm getting too obsessive compulsive with this pin thing
3080 19:35 < sam_moore> It's annoying because ADC, GPIO and PWM are treated completely differently
3081 19:35 < sam_moore> You write one thing and it enables *all* the ADCs
3082 19:35 < sam_moore> You have to enable each GPIO pin individually
3083 19:36 < sam_moore> And to enable PWM pins you give a string (not just an integer)
3084 19:37 < sam_moore> Also the location of the pin files is not guaranteed (though it probably doesn't change for a given system configuration)
3085 19:39 < sam_moore> Ah, I found a way to enable pwm with /sys/class/ instead of that cape manager thing
3086 19:39 < sam_moore> I think I'll use that, since at least it's consistent with the GPIO stuff
3087 19:41 < sam_moore> Ooh!
3088 19:41 < sam_moore> http://beagleboard-gsoc13.blogspot.com.au/2013/07/sampling-analogue-signals-using-adc-on.html
3089 19:41 < sam_moore> Provides a driver for continuously sampling with the ADC
3090 19:41 < sam_moore> Oh wait
3091 19:41 < sam_moore> Crap in a bucket
3092 19:42 < sam_moore> Because we're using those multiplexers we can't do that
3093 19:42 < sam_moore> We have to set the multiplexer before each sample
3094 19:42 < sam_moore> Oh well, never mind
3095 19:44 < sam_moore> I suppose we could write our own kernel module :S
3096 19:45 < sam_moore> I think I understand this enough to talk to Adam next time he tries to talk about sample rate
3097 19:46 < sam_moore> 1. It's not actually constant, but we can probably have it constant to within a few us
3098 19:46 < sam_moore> 2. To make it constant would require writing a kernel module
3099 19:47 < sam_moore> Unless electronics stops being stingy and gets one amplifier per channel :P
3100 20:22 < jtanx> hehehe
3101 20:22 < jtanx> next week's adrian though
3102 20:22 < sam_moore> Ah
3103 20:23 < jtanx> grilling time
3104 20:23 < sam_moore> He'll probably ask us the same things :P
3105 20:23 < jtanx> yeah
3106 20:23 < jtanx> but man, so much stuff to go through just to get some readings from a few pins
3107 20:24 < jtanx> so good job with that :P
3108 20:54 < sam_moore> Thanks
3109 22:45 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3110 --- Day changed Sun Sep 22 2013
3111 00:51 < sam_moore> Hell yes
3112 00:51 < sam_moore> PWM controlled through web browser
3113 00:51 < sam_moore> GPIO controlled through web browser
3114 01:19 < sam_moore> .... And ADC read through web browser
3115 01:19 < sam_moore> Blergh
3116 01:28 < sam_moore> I think I'll take the rest of today off from MCTX3420 :S
3117 08:21 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3118 09:32 -!- jtanx [[email protected]] has quit [Ping timeout]
3119 11:36 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3120 11:53 < sam_moore> I've analysed the crap out of sampling rates for this ADC
3121 11:53 < sam_moore> At least as much as I can just using the timestamps according to gettimeofday
3122 11:54 < sam_moore> Contrary to my first email, reading the ADC is actually really slow. And also probably the greatest source of variation in sampling rate.
3123 11:56 < jtanx> wow
3124 11:56 < jtanx> only 100Hz?
3125 11:56 < sam_moore> Well it looks more like 1KHz on the oscilloscope, but there's a lot of variation, it has trouble getting a trigger
3126 11:57 < jtanx> the cpu datasheet rates it at 200kSPS
3127 11:57 < sam_moore> Hmm
3128 11:58 < sam_moore> Well judging by the control it is something about the ADC reading that makes it really slow
3129 11:58 < jtanx> That's annoyng
3130 11:58 < sam_moore> Yeah
3131 11:58 < sam_moore> Also annoying is that the ADC file is generally in a different place each time they're enabled
3132 11:59 < sam_moore> I ended up modifying the program to take the path to the ADC file as an argument
3133 11:59 < sam_moore> And making run.sh do the initialisation
3134 11:59 < sam_moore> I figured that was better than calling system()
3135 11:59 < jtanx> that makes sense
3136 11:59 < sam_moore> Yep, we might want to set other options that run.sh can pass to it anyway
3137 12:00 < sam_moore> Ok, I have to stop now, I'm spending way to much time on this
3138 12:00 < jtanx> Haha
3139 12:00 < sam_moore> It's getting to the point where I'm considering writing an ADC kernel module that doesn't suck :S
3140 12:01 < jtanx> :S let's hope it doesn't get to that stage
3141 14:08 -!- jtanx [[email protected]] has quit [Connection reset by peer]
3142 14:25 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3143 14:37 -!- MctxBot [[email protected]] has quit [Ping timeout]
3144 15:21 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3145 20:12 < jtanx> the pressure regulator has a 1-5vdc analogue output
3146 20:12 < jtanx> is this considered one of the pressure sensors?
3147 20:14 < jtanx> or maybe it's just not used
3148 21:50 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3149 --- Day changed Mon Sep 23 2013
3150 07:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3151 08:51 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3152 19:38 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3153 19:41 -!- MctxBot [[email protected]] has quit [Ping timeout]
3154 20:55 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3155 21:02 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3156 22:33 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
3157 --- Day changed Tue Sep 24 2013
3158 13:56 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3159 14:18 < jtanx> with kernel 3.8 they decided to make life hard with device tree overlays
3160 14:19 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/277811.aspx
3161 14:19 < jtanx> https://docs.google.com/a/beagleboard.org/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub
3162 14:47 < jtanx> huh
3163 14:47 < jtanx> http://www.youtube.com/watch?v=6gv3gWtoBWQ
3164 14:47 < jtanx> http://digital-drive.com/?p=146
3165 15:39 < sam_moore> I wonder if I can write a module that just uses /dev/adcX /dev/gpioX and /dev/pwmX
3166 15:40 < jtanx> that would make life simple
3167 15:40 < jtanx> but no
3168 15:42 < sam_moore> http://www.tldp.org/LDP/lkmpg/2.6/html/x569.html
3169 15:42 < sam_moore> Probably out of date (2.6?)
3170 15:45 < sam_moore> Also rt.wiki.kernel.org - realtime linux supposedly gives you better timing accuracy, although it would possibly break with our setup involving nginx
3171 15:46 < sam_moore> Actually it looks like there are quite a few ways for it to not work
3172 15:48 < jtanx> I think trying to write a kernel module would cause more grief than it's worth
3173 15:50 < jtanx> http://saadahmad.ca/using-pwm-on-the-beaglebone-black/
3174 15:51 < jtanx> I have no idea what's been updated and what hasn't
3175 15:51 < jtanx> as in, do we have that fix in our kernel
3176 15:53 < sam_moore> I don't know
3177 15:54 < sam_moore> We only need 1 PWM though
3178 16:00 < sam_moore> Or at least, last we heard there was only one. Doesn't make the system very expandable though.
3179 19:07 < jtanx> you know what I'll try loading an Ubuntu image from rcn to my sd card
3180 19:08 < jtanx> instead of from armhf
3181 19:08 < jtanx> armhf.com*
3182 19:17 < jtanx> ah screw it
3183 19:17 < jtanx> i'll stick with debian (but do the same thing)
3184 21:07 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3185 21:34 -!- MctxBot [[email protected]] has quit [Ping timeout]
3186 --- Day changed Wed Sep 25 2013
3187 08:41 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3188 11:31 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3189 12:15 < jtanx> I think I know why we were having issues with pwm yesterday
3190 12:16 < jtanx> if you do this command
3191 12:16 < jtanx> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.8/slots
3192 12:16 < jtanx> you make it unavailable from /sys/class/pwm
3193 12:16 < jtanx> so in the run.sh script it was exporting all the pwm devices via the first method
3194 12:16 < jtanx> and then it becomes unavailable via sysfs
3195 12:17 < jtanx> anyway... I tried booting from the rcn image
3196 12:17 < jtanx> it comes with pwm enabled already
3197 12:17 < jtanx> and via that capemgr I got pwm to work
3198 12:17 < jtanx> I don't know what /sys/class/pwm/pwm0 corresponds to (which pin)
3199 12:19 < jtanx> the electronics teams' bbb wasn't done properly when we tried to upgrade the kernel
3200 12:19 < jtanx> probably something to do with the device tree stuff
3201 12:19 < jtanx> so I flashed it with the rcn image (which runs 3.8.13-bone26
3202 12:20 < jtanx> (demo image from here)
3203 12:20 < jtanx> elinux.org/BeagleBoardDebian
3204 12:47 -!- jtanx [[email protected]] has quit [Ping timeout]
3205 13:09 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
3206 13:09 -!- jtanx_ is now known as jtanx
3207 13:16 < jtanx> oh
3208 13:16 < jtanx> so it now works
3209 13:16 < jtanx>  echo bone_pwm_P9_22 > slots
3210 13:16 < jtanx> if I do that line for pwm0
3211 13:26 < jtanx> oh right
3212 13:26 < jtanx> echo bone_pwm_P9_21 >slots 
3213 13:26 < jtanx> for pwm1
3214 13:30 < jtanx> ahhhhhh
3215 13:30 < jtanx> if you comment out the line
3216 13:30 < jtanx> modprobe pwm_test
3217 13:30 < jtanx> from run.sh
3218 13:30 < jtanx> it works
3219 13:43 < jtanx> geeze kernel 3.8 has issues with usb hotplugging 
3220 13:43 < jtanx> https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/usb/beagleboard/8aalvyWwaig/MUXAPuMTSOYJ
3221 13:43 < jtanx> which explains why we're having issues with cameras
3222 13:43 < jtanx> (partly at least)
3223 13:47 < jtanx> and now pwms not working again
3224 13:48 < jtanx> via sysfs
3225 13:50 < jtanx> oh
3226 13:50 < jtanx> I know why
3227 13:51 < jtanx> you have to export it /sys/class/pwm
3228 13:51 < jtanx> first
3229 13:51 < jtanx> *before* you do stuff like       echo bone_pwm_P9_21 >slots 
3230 13:52 < jtanx> yep 
3231 13:53 < jtanx> so the order is: echo 0/1 > /sys/class/pwm/export
3232 13:53 < jtanx> then do that other stuff
3233 13:57 < jtanx> egh
3234 13:57 < jtanx> finnicky
3235 13:57 < jtanx> ok I have to stop now
3236 14:14 -!- jtanx [[email protected]] has quit [Ping timeout]
3237 14:15 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3238 15:46 -!- jtanx [[email protected]] has quit [Ping timeout]
3239 16:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3240 16:04 < jtanx> well that was an interesting experience
3241 16:04 < jtanx> it's most reliable when you work directly with /sys/devices/ocp2.helper/PWM9_22*
3242 16:05 < jtanx> I think if you echo am33xx_pwm to the slots thing when it's already loaded
3243 16:05 < jtanx> weird shit can happen
3244 16:05 < jtanx> too
3245 16:07 < jtanx> setting the period via sysfs (eg /sys/class/pwm) didn't work most of the time either
3246 16:07 < jtanx> you could change duty but not period
3247 16:07 < jtanx> although I swear I had it working at one point
3248 16:07 < jtanx> via the other way I think it works ok
3249 16:08 < jtanx> oh yeah, and I was doing this using the demo image from http://elinux.org/BeagleBoardDebian
3250 16:09 < jtanx> the electrical group's one has been reflashed with that version as well
3251 16:09 < jtanx> (for ours I worked off my sd card)
3252 16:10 < jtanx> that image also enables the ethernet-over-usb 
3253 16:36 < jtanx> I think we have to be careful which pins we export/enable
3254 16:37 < jtanx> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
3255 16:37 < jtanx> pages 80-82
3256 16:37 < jtanx> the pins have different meanings based on what mode they're in
3257 16:41 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3258 17:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3259 18:05 < jtanx> ...so I brought the BBB home, even though I should be studying for 2402 :S
3260 18:05 < jtanx> the microphone came in today too
3261 18:19 < jtanx> ok
3262 18:19 < jtanx> so these documents: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
3263 18:19 < jtanx> describes what the pins are  used for by default
3264 19:00 < sam_moore> Ah... they already got the microphone
3265 19:00 < sam_moore> Welp. Guess we're stuck with it.
3266 19:00 < sam_moore> So... we can record <50Hz sounds reliably, maybe
3267 19:00 < sam_moore> How useful
3268 19:01 < sam_moore> Have I been missing out on an email stream where the sensors team actually clears things with us?
3269 19:04 < jtanx> not that I know of
3270 19:04 < jtanx> haha
3271 19:04 < jtanx> in other news
3272 19:04 < jtanx> the sensors team ordered a pressure sensor with no mount
3273 19:04 < jtanx> adrian had a spat because it'd cost something like $200 to make the mount
3274 19:05 < jtanx> for a $10 part
3275 19:05 < jtanx> so he said, order it from online , I don't care if it's from overseas
3276 19:05 < sam_moore> Oh boy
3277 19:06 < sam_moore> If there's an issue with the camera and/or microphone they'll blame us
3278 19:06 < jtanx> yeah
3279 19:06 < jtanx> about that camera
3280 19:06 < sam_moore> Oh dear...
3281 19:06 < sam_moore> Go ahead?
3282 19:06 < jtanx> still couldn't get it to work today
3283 19:06 < sam_moore> God dammit
3284 19:06 < jtanx> although I didn't spend much time on it
3285 19:06 < jtanx> I got pwm to work
3286 19:06 < jtanx> mostly
3287 19:06 < sam_moore> I thought it might be something like adding the user to the "video" group
3288 19:06 < sam_moore> That's good!
3289 19:07 < sam_moore> What was happening?
3290 19:07 < jtanx> yeah, the problem is it doesn't show up at all (the camera)
3291 19:07 < sam_moore> Hmm
3292 19:07 < jtanx> and partly because 3.8 has an issue with usb hotplugging
3293 19:07 < sam_moore> Haha
3294 19:07 < jtanx> about pwm
3295 19:07 < jtanx> it seems that the sysfs method is not so reliable
3296 19:07 < jtanx> you can get it to work
3297 19:07 < jtanx> you have to export those first
3298 19:07 < jtanx> so echo 0 > /sys/class/pwm/export
3299 19:08 < jtanx> then (and only then)
3300 19:08 < jtanx> can you do
3301 19:08 < jtanx> that echo to the slots
3302 19:08 < jtanx> for those pins
3303 19:08 < jtanx> then it seems to be happy
3304 19:08 < jtanx> if you echo am33xx_pwm to the slots when it's already enabled
3305 19:08 < jtanx> that also screws things up
3306 19:08 < sam_moore> Ok
3307 19:09 < sam_moore> Thanks for working that out
3308 19:09 < jtanx> yeah
3309 19:09 < sam_moore> If you want to change from sysfs to the other method that's fine
3310 19:09 < sam_moore> But sysfs was much simpler to code
3311 19:09 < jtanx> should have spent that time studying for mech2402 though :P
3312 19:09 < sam_moore> Because you just sprintf an integer to the path
3313 19:09 < jtanx> yeah
3314 19:09 < jtanx> witht he other way it's all that dynamic path crap
3315 19:09 < sam_moore> Rather than keeping track of "bone_pwm_test_P9_22.15.arbitrary_string" crap
3316 19:09 < sam_moore> Exactly :P
3317 19:09 < jtanx> but
3318 19:10 < jtanx> you can enable pwm and analogue on boot
3319 19:10 < jtanx> if I can find the link
3320 19:10 < sam_moore> Sure, if that's easy
3321 19:10 < sam_moore> I figured if we put them in the /etc/init.d script that'd be fine too
3322 19:10 < sam_moore> Actually... maybe we should put it in the /etc/init.d script
3323 19:11 < jtanx> oh yeah
3324 19:11 < jtanx> and the demo image from that rcn image
3325 19:11 < sam_moore> Because if someone gets a different beaglebone then they'd have to reenable it on boot
3326 19:11 < jtanx> is better than screwing around with recompiling kernels
3327 19:11 < sam_moore> Can you give a link?
3328 19:11 < jtanx> I think it's the first image that you had originally
3329 19:11 < jtanx> http://elinux.org/BeagleBoardDebian
3330 19:12 < jtanx> there's this script in /boot
3331 19:12 < sam_moore> Oh
3332 19:12 < jtanx> that allows you to copy the sd card to flash
3333 19:12 < jtanx> it also enables the usb over ethernet
3334 19:12 < sam_moore> Oh right, the image I downloaded before we used yours
3335 19:12 < sam_moore> Cool
3336 19:12 < jtanx> yeah
3337 19:12 < jtanx> I flashed electronics' one with that
3338 19:12 < sam_moore> Does PWM and stuff work on it?
3339 19:13 < jtanx> probably
3340 19:13 < jtanx> I was using the same image
3341 19:13 < jtanx> on ours
3342 19:13 < jtanx> you run this script and it copies exatly what's on the sd card to the internal flash
3343 19:13 < jtanx> resizes the partition as necessary
3344 19:13 < jtanx> http://digital-drive.com/?p=146
3345 19:13 < jtanx> that page shows how to enable on boot
3346 19:13 < jtanx> it's just a change to uEnv.txt in the boot partition
3347 19:18 < sam_moore> Good work
3348 19:19 < sam_moore> While I remember, for multiple logins and crap... can you just try to login as a local user account?
3349 19:19 < sam_moore> Then we could make a wrapper around adduser and deluser for the "administrator" account
3350 19:19 < jtanx> wow
3351 19:20 < jtanx> I don't know
3352 19:20 < sam_moore> I was just thinking
3353 19:20 < sam_moore> Linux has a user account system already
3354 19:20 < jtanx> yep, but is it a good idea to be making ~300 on a BBB?
3355 19:21 < sam_moore> Well... putting LDAP on the BBB probably won't be less intense
3356 19:21 < sam_moore> I know it's called "Lightweight"
3357 19:21 < sam_moore> But that's in comparison to "DAP"
3358 19:21 < jtanx> well to be perfectly honest, adrian is asking way too much
3359 19:21 < sam_moore> Which was designed in the 1980s by a telephone directory company and used the original OSI networking model
3360 19:21 < jtanx> you simply can't support a 300-odd user base on something like a BBB
3361 19:21 < sam_moore> Yeah
3362 19:22 < sam_moore> But maybe something like 30 users would work?
3363 19:22 < jtanx> yeah
3364 19:22 < jtanx> let's just keep it at that limit
3365 19:22 < sam_moore> Another thing regarding the crazy requirements...
3366 19:22 < sam_moore> If we have multiple Beaglebones running FastCGI
3367 19:23 < sam_moore> We can design our GUI so that it has links to the appropriate Beaglebone for each function
3368 19:23 < sam_moore> I don't think we actually need to do anything in nginx or the Beaglebone software
3369 19:24 < jtanx> hmm
3370 19:24 < sam_moore> At least in terms of displaying sensor data
3371 19:24 < sam_moore> For actuator control, we would need to introduce networking between individual beaglebones
3372 19:24 < jtanx> it actually depends on what he means by 'extensible' and/or distributed
3373 19:24 < jtanx> like
3374 19:24 < jtanx> you could say this BBB is for this experiement
3375 19:25 < jtanx> this other BBB is for this other experiment
3376 19:25 < sam_moore> But quite frankly you'd be mad to trust a distributed system with networking delays to coordinate control over hardware
3377 19:25 < jtanx> well yeah
3378 19:25 < sam_moore> Well at least something like this where we care about safety
3379 19:25 < sam_moore> But if you keep the actual control over hardware independent and on seperate devices
3380 19:25 < jtanx> but I mean
3381 19:26 < jtanx> wait 
3382 19:26 < jtanx> if we interpret it as meaning
3383 19:26 < jtanx> that each BBB runs an instance of the software
3384 19:26 < jtanx> then they would still be separate
3385 19:26 < jtanx> as in each BBB controls one 'experiment'
3386 19:26 < jtanx> you customise each BBB based on the experiment that needs to be done
3387 19:26 < sam_moore> Yes, that would work
3388 19:26 < sam_moore> Yep
3389 19:26 < jtanx> then there's no interaction between BBBS
3390 19:27 < jtanx> the only thing is you have some sort of control at the front
3391 19:27 < jtanx> that determines which BBB you connect to
3392 19:27 < sam_moore> Yes, if there's interaction between BBBs it gets problematic
3393 19:27 < jtanx> yeah
3394 19:27 < sam_moore> Yes, you have one BBB which gives the user the "main menu" part of the GUI
3395 19:27 < jtanx> I reckon that's a stupid requirement to ask
3396 19:27 < jtanx> yeah
3397 19:27 < sam_moore> Then the others just have customised GUIs or whatever
3398 19:28 < jtanx> once you have to get them to talk to each other, you're then having to try and invent a whole new protocol
3399 19:28 < jtanx> for that
3400 19:28 < sam_moore> Yeah, and it depends on exactly what the hardware is
3401 19:29 < sam_moore> You might be able to hack it onto the web protocol (eg: BeagleBone #1 sends http://beaglebone2/api/actuators?id=X?set=Y)
3402 19:29 < sam_moore> But... let's not think about that
3403 19:30 < sam_moore> It's clearly beyond the scope of this project
3404 19:31 < sam_moore> So, after all that, I reckon if we use snoopy for ADC/GPIO/PWM and spike for the dilatometer then that would be cool (probably not actually necessary though)
3405 19:31 < jtanx> yeah
3406 19:32 < sam_moore> The dilatomter... it's going to cause headaches if Kieren really wants to "return" an array of points
3407 19:33 < sam_moore> If the goal is to provide the user with a demonstration of what the dilatometer is doing, then you can just edit an image
3408 19:33 < sam_moore> If the goal is to provide more data... I don't see the point really
3409 19:34 < sam_moore> It's going to be the same sort of distribution every time
3410 19:34 < sam_moore> Realistically all anyone would do is average it
3411 19:34 < sam_moore> Maybe take a standard deviation
3412 19:36 < jtanx> I really don't know why a dilatometer's even needed
3413 19:36 < sam_moore> Educational reasons? :P
3414 19:37 < jtanx> haha sure
3415 19:37 < sam_moore> Anyway, hopefully Callum will deal with the dilatometer stuff
3416 19:37 < sam_moore> The interferometer code is a good starting point
3417 19:39 < jtanx> Yeah
3418 19:39 < jtanx> hopefully
3419 19:42 < sam_moore> We should arrange some meetings next week
3420 19:42 < sam_moore> Also I'd like to see more of the other group members committing to git and talking in this channel
3421 19:45 < sam_moore> People are missing a lot of design decisions here :S
3422 19:45 < jtanx> Yeah
3423 19:51 < jtanx> Ok
3424 19:51 < jtanx> so I made a LUT from pin number on the board to GPIO pin number
3425 19:52 < jtanx> so if you wanted to use P8_13
3426 19:52 < jtanx> you can use the lut to figure out what gpio number that corresponds to
3427 19:53 < jtanx> we should probably restrict which pins can be used
3428 19:53 < jtanx> because quite a few are reserved
3429 19:53 < sam_moore> Sure
3430 19:53 < sam_moore> Remove the #defines in bbb_pin_defines.h ?
3431 19:54 < sam_moore> Don't export those pins in pin_test.c
3432 19:54 < sam_moore> It is only really for testing anyway
3433 19:54 < jtanx> yeah
3434 19:55 < sam_moore> Although... I predict if we leave it in the software, *someone* at some point will try and control hardware directly through it :P
3435 19:55 < sam_moore> For all the educational stuff it's nice though
3436 19:56 < sam_moore> Oh, we could have an image of the pinout diagram
3437 19:56 < sam_moore> And when someone clicks on a part of the image they get to control that pin
3438 19:57 < sam_moore> Anyway... I really should study for MECH2402 or I will fail it
3439 19:57 < sam_moore> So bye
3440 19:57 < jtanx> yeah
3441 19:57 < jtanx> bye
3442 20:50 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3443 21:50 -!- MctxBot [[email protected]] has quit [Ping timeout]
3444 --- Day changed Thu Sep 26 2013
3445 07:45 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3446 08:36 -!- jtanx [[email protected]] has quit [Ping timeout]
3447 09:36 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3448 10:47 -!- jtanx [[email protected]] has quit [Ping timeout]
3449 13:08 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3450 16:26 -!- jtanx [[email protected]] has quit [Ping timeout]
3451 17:04 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3452 17:52 < jtanx> http://www.ti.com/lit/ug/spruh73i/spruh73i.pdf p1986 (chapter 15) on pwm
3453 17:55 < jtanx> page 1996 on ePWM
3454 17:56 < jtanx> ahhhhh
3455 17:56 < jtanx> for ehrpwm0a/0b
3456 17:56 < jtanx> the frequency is linked
3457 18:08 < jtanx> ehrpwm is enhanced resolution pwm
3458 18:08 < jtanx> Implemented using the A signal path of PWM, that is, on the EPWMxA output. EPWMxB output has
3459 18:08 < jtanx> conventional PWM capabilities
3460 18:08 < jtanx> (p2053)
3461 19:06 < jtanx> if you want to make the pwm stuff not suck
3462 19:06 < jtanx> there's this file called pwm_test.c
3463 19:06 < jtanx> that's the driver
3464 19:59 < jtanx> for future ref: http://armsdr.blogspot.com.au/2013/04/archlinux-on-beaglebone-and-linux-38.html
3465 20:08 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
3466 20:21 -!- jtanx [[email protected]] has quit [Ping timeout]
3467 21:19 < jtanx_> urgh wow
3468 21:19 < jtanx_> ok, so I think pwm1/3/5 shouldn't be used to avoid period conflicts
3469 21:19 < jtanx_> (pwm0/1 is for channel A/B of one pwm device, 3/4 another, 5/6 another)
3470 21:20 < jtanx_> btw the correspondence between pwmX and pin number is:
3471 21:21 < jtanx_> P9_22, P9_21, P9_42. P9_14, P9_16, P8_19, P8_13, P9_28
3472 21:23 < jtanx_> pwm 2/7 correspond to eCAP devices
3473 21:24 < jtanx_> which I think are to capture PWM input
3474 21:24 < jtanx_> but they can also be used to generate PWM output, afaik
3475 23:08 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3476 23:10 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3477 --- Day changed Fri Sep 27 2013
3478 12:38 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3479 13:29 < jtanx> so, apparently if we don't order stuff that we need before the mid semester break (ie today), adrian just won't order it
3480 13:29 < jtanx> in other news, I think I've mostly sorted out pwm
3481 13:43 < jtanx> trying to standardise the pin code
3482 15:05 -!- jtanx [[email protected]] has quit [Ping timeout]
3483 15:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3484 16:09 -!- MctxBot [[email protected]] has quit [Ping timeout]
3485 19:48 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
3486 20:03 -!- jtanx [[email protected]] has quit [Ping timeout]
3487 20:10 < jtanx_> lol
3488 20:10 < jtanx_> we have a file authored '14 years ago'
3489 20:10 < jtanx_> in git
3490 20:10 < jtanx_> talk about commitment
3491 20:20 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3492 21:47 < jtanx_> so on non-BBB platforms, I disabled the pin code
3493 21:47 < jtanx_> required some pretty dubious hacks to stop gcc from complaining
3494 21:48 < jtanx_> 1st attempt: define the functions to nothing
3495 21:48 < jtanx_> gcc complains about statements that do nothing
3496 21:48 < jtanx_> various combinations later on statements that do nothing, I move to making function stubs
3497 21:49 < jtanx_> shaft all the parameters to the stubs
3498 21:49 < jtanx_> to stop complaints about unused variables
3499 21:49 < jtanx_> (eg if you did int freq=1000; PWM_Set(...,freq) where the define for PWM_Set doesn't use freq
3500 21:53 -!- jtanx_ [[email protected]] has quit [">.>"]
3501 22:14 -!- MctxBot [[email protected]] has quit [Ping timeout]
3502 22:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3503 22:20 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3504 23:12 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3505 --- Day changed Sat Sep 28 2013
3506 10:03 -!- MctxBot [[email protected]] has quit [Ping timeout]
3507 11:07 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3508 --- Log closed Sat Sep 28 12:20:39 2013
3509 --- Log opened Sat Sep 28 12:26:58 2013
3510 12:26 -!- sam_moor1 [[email protected]] has joined #mctxuwa_softdev
3511 12:26 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
3512 12:27 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
3513 12:31 -!- sam_moore [[email protected]] has quit [Ping timeout]
3514 13:18 -!- jtanx [[email protected]] has quit [Ping timeout]
3515 18:26 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3516 18:53 -!- jtanx [[email protected]] has quit [Ping timeout]
3517 20:17 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3518 21:36 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3519 --- Log closed Sun Sep 29 08:28:33 2013
3520 --- Log opened Sun Sep 29 08:31:40 2013
3521 08:31 -!- matches [[email protected]] has joined #mctxuwa_softdev
3522 08:31 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
3523 08:31 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
3524 08:31 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
3525 08:31 -!- You're now known as sam_moore
3526 13:18 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3527 15:27 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3528 15:27 < Rowan> hey jeremy, did you upload the updated gui onto a github? i cant find it anywhere ??
3529 15:32 < sam_moore> Hi Rowan, I think it's in a few subdirectories
3530 15:33 < sam_moore> Ah, it's under "testing/MCTXWeb"
3531 15:33 < sam_moore> https://github.com/szmoore/MCTX3420/tree/master/testing/MCTXWeb/public_html
3532 15:37 < Rowan> thats the most uptodate version?
3533 15:39 < jtanx> um
3534 15:39 < jtanx> maybe
3535 15:39 < jtanx> I'll update with what I've got now
3536 15:42 < jtanx> ok
3537 15:42 < jtanx> updated
3538 15:42 < jtanx> pintest stuff still not complete
3539 15:42 < Rowan> are you guys busy?
3540 15:42 < Rowan> (will you be on here long?
3541 15:42 < jtanx> right now I'm working on that pintest page
3542 15:42 < jtanx> I'm here
3543 15:43 < Rowan> in g19?
3544 15:43 < jtanx> no
3545 15:43 < jtanx> I'm at home
3546 15:43 < Rowan> okay
3547 15:43 < sam_moore> jtanx: As in, the pin control code isn't working? I didn't think I screwed it up that badly?
3548 15:43 < jtanx> nah 
3549 15:43 < jtanx> the pin control web page
3550 15:43 < sam_moore> Oh, nice
3551 15:43 < jtanx> just thought it'd be easier to have a webpage to control stff
3552 15:43 < sam_moore> Yes
3553 15:43 < jtanx> especially for electronics
3554 15:43 < sam_moore> Yes, definitely
3555 15:44 < Rowan> are we going to make the gui UWA based or make it our own ?
3556 15:44 < Rowan> adrian made it sound like he wanted it UWA based with the logo and stuff
3557 15:44 < jtanx> we probably have to add uwa logo
3558 15:44 < sam_moore> We should probably put the UWA logo on it
3559 15:44 < sam_moore> Yes
3560 15:45 < Rowan> so make it similar to the main UWA page or make it similar to LMS?
3561 15:46 < Rowan> does anyone know if IT are in this week?
3562 15:46 < jtanx> we need to make it Colourful
3563 15:47 < jtanx> I don't think it needs to be exactly like UWA page or LMS
3564 15:47 < jtanx> just something similar would be good
3565 15:47 < sam_moore> I think LMS is probably a bad example, lots of people hate it
3566 15:48 < jtanx> haha
3567 15:48 < jtanx> I think LMS is fine, although there seems to be alot of problems with it on the backend
3568 15:48 < Rowan> yeah but adrian loves it
3569 15:48 < Rowan> keeting uses it for all 5 units hes teaching
3570 15:49 < Rowan> has anyone heard from james about the gui, i think he uploaded something to dropbox
3571 15:49 < jtanx> really
3572 15:49 < jtanx> I haven't checked db
3573 15:49 < jtanx> why's he not using git
3574 15:50 < Rowan> i dont know. has he uploaded anything to it/
3575 15:50 < Rowan> he might be.
3576 15:50 < Rowan> sometime last week he said he made up a gui todo list type thing but i dont know where he put it
3577 15:50 < sam_moore> It doesn't look like there is anything in dropbox
3578 15:50 < jtanx> right
3579 15:51 < Rowan> im trying to get in contact with him but i might just move on. so we want something somewhat related to lms?
3580 15:51 < Rowan> or no?
3581 15:52 < sam_moore> I think so, although it primarily needs to be able to control experiments
3582 15:52 < sam_moore> For the educational stuff, you could use a wiki style
3583 15:53 < sam_moore> https://github.com/szmoore/MCTX3420/wiki
3584 15:54 < Rowan> wiki isnt graphical enough
3585 15:54 < sam_moore> Yeah, probably
3586 15:54 < Rowan> its hard to say what adrian wants....
3587 15:54 < sam_moore> It looks like James has committed something to his own fork of the repository
3588 15:55 < jtanx> ok
3589 15:55 < sam_moore> https://github.com/firefields/MCTX3420/commit/e6a8120fdf1cef6d73421bd2b1edb1c45a6f3960
3590 15:55 < sam_moore> I can pull that into the main fork
3591 15:55 < sam_moore> Hopefully
3592 15:55 < jtanx> I think that may actually be
3593 15:56 < jtanx> sorry
3594 15:56 < jtanx> my computer decided to freeze at that instant
3595 15:57 < jtanx> but yeah that's the stuff
3596 15:57 < jtanx> he worked on 
3597 15:57 < sam_moore> Oh wow... there are a *lot* of files
3598 15:57 < jtanx> before mine
3599 15:57 < jtanx> it's all the jquery ui stuff
3600 15:57 < sam_moore> jquery-ui
3601 15:57 < sam_moore> Yes
3602 15:57 < jtanx> wich I  told him to get rid off
3603 15:57 < sam_moore> Dammit I just merged it :S
3604 15:57 < jtanx> but yeah, he hasn't committed anything since
3605 15:58 < jtanx> (that commit was done with me at the last meeting)
3606 15:58 < Rowan> so are we deciding on jeremys version it seems alot more complete
3607 15:59 < sam_moore> Yes, stick with Jeremy's and build on it
3608 15:59 < Rowan> sweet :)
3609 16:46 < Rowan> what was the password and username ?
3610 16:48 < jtanx> there's none
3611 16:48 < jtanx> if you haven't set up the htpasswd thing
3612 16:48 < jtanx> (ie it doesn't work)
3613 16:48 < jtanx> still not sure how to implement it either
3614 16:48 < jtanx> now that adrian wants it scalable to '300 students'
3615 16:53 < jtanx> I need another network switch...
3616 16:53 < Rowan> okay.
3617 16:53 < Rowan> i might make up a cover page, which links to the one we have after you log in
3618 16:54 < Rowan> like this but simpler: http://www.futureeffect.com.au/
3619 16:54 < Rowan> with a scrolling picture thing and stuff
3620 16:54 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3621 16:55 < MctxBot> I live again...
3622 16:55 < Rowan> whos mctxbot again?
3623 16:56 < jtanx> :P
3624 16:56 < jtanx> It does nothing
3625 16:56 < Rowan> its a cover page
3626 16:56 < Rowan> its what adrian said
3627 16:56 < jtanx> It connects whenever mctx.us.to is running
3628 16:57 < Rowan> what what
3629 16:57 < Rowan> ?
3630 16:58 -!- MctxBot changed the topic of #mctxuwa_softdev to: MCTX3420 - Software and co.
3631 16:59 < jtanx> mctxbot is no one, it's the server I operate
3632 17:02 < Rowan> hahahahah
3633 17:02 < Rowan> oh.
3634 17:03 < Rowan> ive put the uwa logo onto the gui
3635 17:09 < sam_moore> I'm looking at the login stuff
3636 17:10 < sam_moore> So... we probably don't want to use shell accounts, since once you have shell access you can do all sorts of things that are completely unrelated to this educational stuff
3637 17:10 < Rowan> could someone check ive forked it right
3638 17:10 < sam_moore> I think storing our own file in the same format as /etc/shadow is probably ok
3639 17:11 < Rowan> the gui.html & style.css
3640 17:12 < sam_moore> It looks like you've made a new branch for each of the files?
3641 17:12 < Rowan> i think so
3642 17:12 < Rowan> do you need to update the main file and i request it to you
3643 17:13 < Rowan> just so everything is uptodate and and organised
3644 17:13 < sam_moore> You submitted a pull request, that's fine
3645 17:13 < sam_moore> Yep
3646 17:13 < Rowan> both html and css files
3647 17:13 < sam_moore> You should probably keep edits in the "master" branch, or at least don't make a seperate branch for each file
3648 17:14 < sam_moore> (That way you only have to do one pull request for all of them, not one per file)
3649 17:14 < Rowan> how do i do that :|
3650 17:14 < sam_moore> Are you using a GUI or the command line?
3651 17:15 < Rowan> gui
3652 17:15 < jtanx> I think you were working on an old version
3653 17:15 < jtanx> before I pushed the new one
3654 17:15 < sam_moore> Hmm
3655 17:15 < jtanx> so some stuff got deleted
3656 17:15 < Rowan> S***
3657 17:15 < jtanx> https://github.com/szmoore/MCTX3420/commit/f43006da69d629d0c5421506c8a56d517b94924e
3658 17:15 < jtanx> it's ok
3659 17:16 < sam_moore> jtanx: It should have complained if there was a conflict?
3660 17:16 < jtanx> I dunno
3661 17:16 < Rowan> i only added 1 line to the css file anyways
3662 17:16 < jtanx> yeah
3663 17:16 < jtanx> so the form.controls, div.centre .bold etc
3664 17:16 < jtanx> stuff was added later
3665 17:18 < Rowan> when im home ill try put a cover page with pictures and the login page on it and link the login page to the gui we have atm.
3666 17:18 < Rowan> any constructive critism ?
3667 17:19 < Rowan> also ill try be on irc for the rest of the sem to keep up todate with you guys :)
3668 17:21 < sam_moore> The future effect looks cool
3669 17:21 < sam_moore> I guess we need to pick some relevant images though
3670 17:21 < Rowan> yeah ill talk to some other teams and see if they have any cool pics, like the can were testing, the cad model ect
3671 17:22 < Rowan> ttyl
3672 17:22 < jtanx> has this been pushed to your (sam's) repo?
3673 17:22 < sam_moore> I accepted a pull request a while ago
3674 17:22 < sam_moore> But I noticed Rowan has two branches in his fork; there's one file changed in each branch
3675 17:23 < jtanx> oh ok
3676 17:23 < jtanx> because I don't see any change except for some css stuff in your repo
3677 17:24 < sam_moore> Rowan: I'll try and get in earlier tomorrow to help with the "branching" stuff in git
3678 17:25 < sam_moore> It looks like your git GUI might have some wierd settings
3679 17:28 < MctxBot> damn ircnet
3680 17:29 < MctxBot> 'Too many user connections (local))'
3681 17:29 < MctxBot> so i'll steal mctxbot for now
3682 17:38 -!- Rowan [[email protected]] has quit [Ping timeout]
3683 17:42 -!- jtanx [[email protected]] has quit [Ping timeout]
3684 17:42 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
3685 17:42 -!- jtanx_ is now known as jtanx
3686 17:43 < jtanx> finally
3687 17:52 < sam_moore> So, we can implement our own login system fairly easily, I'm not sure if we want to or not, although I'm leaning towards just doing it
3688 17:53 < sam_moore> It wouldn'
3689 17:54 < sam_moore> t necessarily be the best solution in terms of flexibility
3690 17:54 < sam_moore> But it's probably a hell of a lot more "lightweight" than LDAP
3691 17:55 < sam_moore> Using LDAP you'd have to dedicate processes just to being a login server
3692 17:56 < sam_moore> So... we provide some wrappers around a text file of usernames and password salts, and allow "admin" to use wrappers that change the files
3693 17:57 < sam_moore> ... I suppose we can have a "forgot password" functionality
3694 17:57 < sam_moore> Though it is certainly a pain
3695 17:59 < sam_moore> I feel like we should have "forgot password" but make it ridiculously painful to use, for revenge
3696 17:59 < sam_moore> ...errr I mean security reasons
3697 17:59 < sam_moore> Did I say "revenge?"
3698 18:00 < sam_moore> "Forgot password" should activate one of the ADC channels and record the average over 10s
3699 18:01 < sam_moore> And you have to enter what it was
3700 18:01 < sam_moore> No wait, any student could do that
3701 18:01 < sam_moore> Hmmm
3702 18:03 < sam_moore> "Your password has been sent via Australia Post to your registered address"
3703 18:04 < jtanx> hahaha
3704 18:04 < jtanx> evil
3705 18:04 < jtanx> I was kinda hoping there was some ready made
3706 18:04 < jtanx> gateway software
3707 18:05 < jtanx> like you know the SSO services that uwa uses
3708 18:05 < sam_moore> Yeah, that's an LDAP gateway
3709 18:05 < jtanx> yeah but like a simplified version
3710 18:05 < sam_moore> Haha
3711 18:05 < jtanx> that just uses an sql database or something
3712 18:05 < jtanx> slap it on and we're done
3713 18:06 < sam_moore> Yeah I guess we should look for that
3714 18:06 < sam_moore> Do we allow users to change their password?
3715 18:06 < sam_moore> Ooh
3716 18:06 < sam_moore> Our system is on the UWA network...
3717 18:06 < sam_moore> Could we just wrap to UWA's LDAP servers?
3718 18:06 < sam_moore> And... um...
3719 18:07 < jtanx> do they trust us that much?
3720 18:07 < sam_moore> They can't really stop us
3721 18:07 < sam_moore> You can bind to the LDAP servers already
3722 18:07 < sam_moore> It's not like they can...
3723 18:07 < jtanx> really?
3724 18:07 < sam_moore> Put in a login or something
3725 18:07 < sam_moore> That you have to go through first
3726 18:07 < jtanx> well then
3727 18:07 < sam_moore> :P
3728 18:08 < sam_moore> Hang on, there's some horribly verbose way to test it in a shell
3729 18:08 < jtanx> my god why is it so hard to vertically align content in css
3730 18:14 < sam_moore> ldapsearch -x -D cn=20503628,ou=Students,ou=Users,ou=UWA,dc=uwads,dc=uwa,dc=edu,dc=au -h ldap.pheme.uwa.edu.au -W -v -b cn=20503628,ou=Students,ou=Users,ou=UWA,dc=uwads,dc=uwa,dc=edu,dc=au
3731 18:14 < sam_moore> Replace 20503628 with your own student number
3732 18:14 < sam_moore> So
3733 18:14 < sam_moore> Basically we can wrap to ldapsearch using their username and password
3734 18:14 < jtanx> I wonder what adrian has to say about that
3735 18:15 < sam_moore> Well, obviously he doesn't want just *any* student being able to access it :S
3736 18:15 < sam_moore> But...
3737 18:15 < sam_moore> We could have a plain text file of students
3738 18:15 < sam_moore> That he can change
3739 18:15 < sam_moore> Also...
3740 18:16 < sam_moore> UWA IT might have a problem
3741 18:16 < sam_moore> It would be ridiculously easy to put a back door in to steal student's passwords :S
3742 18:16 < jtanx> yeah
3743 18:16 < sam_moore> But... I guess people would just use their pheme password anyway
3744 18:17 < sam_moore> I mean, I would
3745 18:18 < sam_moore> http://xkcd.com/792/
3746 18:18 < sam_moore> I reckon we implement the system to bind to UWA's ldap servers, obviously don't do anything unethical
3747 18:19 < jtanx> :P
3748 18:19 < jtanx> what about jellyfish, calmaeth
3749 18:19 < sam_moore> And warn Adrian that if he lets random students work on this they can potentially do unethical things
3750 18:19 < sam_moore> What do they use for login?
3751 18:20 < jtanx> they roll their own I think
3752 18:20 < jtanx> but obviously there's some way to import users
3753 18:20 < sam_moore> Hmm
3754 18:20 < sam_moore> I like the idea of using UWA's pheme server though
3755 18:21 < sam_moore> Just add a list of allowed student numbers in front of it
3756 18:21 < sam_moore> Actually, staff as well
3757 18:21 < jtanx> yeah true
3758 18:21 < sam_moore> No wait
3759 18:22 < sam_moore> That could end in the staff member accidentally deleting themselves
3760 18:22 < sam_moore> Um...
3761 18:22 < sam_moore> Just hard code in Adrian's staff number as always allowed :P
3762 18:22 < sam_moore> Ergh, so many annoying things that have nothing to do with blowing up a pressure vessel -_-0
3763 18:23 < sam_moore> Ok, I'll try do some more on the login tomorrow
3764 18:23 < jtanx> ok cool
3765 18:23 < jtanx> I'll try to come in early tomorrow too
3766 18:23 < jtanx> though I really should be working on my other projects too...
3767 18:24 < sam_moore> Well, we're doing alright on the list of things Todo
3768 18:24 < sam_moore> Not sure how well we're doing by Adrian's standards
3769 18:24 < sam_moore> Oh, all that GUI stuff isn't getting done very afst
3770 18:24 < sam_moore> *fast
3771 18:24 < jtanx> yeah
3772 18:25 < sam_moore> Also haven't heard anything about image processing from Callum
3773 18:25 < jtanx> I wonder if james has done anything at all
3774 18:25 < sam_moore> Oh well... I'll do logins this week
3775 18:25 < jtanx> Adrian doesn't seem to like how most of the groups are going
3776 18:26 < sam_moore> Well, not much has happened with other groups I suppose
3777 18:26 < sam_moore> We've written a lot of software, but it's all low level
3778 18:26 < jtanx> I also think he underappreciates the effort required for the software though
3779 18:27 < sam_moore> I think so
3780 18:27 < sam_moore> Though we really should have more GUI stuff done
3781 18:28 < jtanx> yeah
3782 18:28 < jtanx> we really do need to make progress on that
3783 18:52 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3784 19:12 < jtanx> firebug slows down my computer so much
3785 19:22 < jtanx> ok I just updated the gui stuff a bit
3786 19:22 < jtanx> ...now back to testing if this pin test html page works
3787 19:32 < jtanx> well hey
3788 19:32 < jtanx> it works
3789 19:33 < jtanx> Should probably do reference counting on the export/unexport stuff though
3790 19:36 < jtanx> actually maybe not
3791 19:40 -!- MctxBot [[email protected]] has quit [Ping timeout]
3792 19:46 < sam_moore> I think DAP (which is what LDAP was based on) wasn't actually meant to be a login system when they designed it :P
3793 19:46 < sam_moore> But it's used for that more than anything else
3794 19:46 < sam_moore> Essentially it was supposed to be like an electronic telephone directory
3795 19:47 < sam_moore> Then they realised that it was a bad idea for any random person to be able to edit stuff, so authentication got added to it
3796 19:47 < sam_moore> And now it's pretty much just used for authentication
3797 19:48 < sam_moore> There seems to be a sane C library for it, so if we just implement a client and rely on the good IT staff at UWA to keep pheme working...
3798 19:49 < sam_moore> (Does UWA even still hire IT staff?)
3799 19:49 < sam_moore> (Someone told me they "integrated" the librarians into IT)
3800 19:50 < sam_moore> We'll need to put our login page under HTTPS at some point
3801 19:52 < jtanx> I was just thinking
3802 19:53 < jtanx> put the whole damn thing under ssl
3803 19:53 < jtanx> and be done with it
3804 19:54 < jtanx> hmm interesting
3805 19:54 < jtanx> if you query the adc on different channels 
3806 19:55 < jtanx> and you query too fast
3807 19:55 < jtanx> it'll spit back that it's temporarily unavailable
3808 19:55 < jtanx> probably can't change the mux that fast?
3809 19:56 < sam_moore> Maybe
3810 19:56 < sam_moore> It's kind of ironic that the ADC hardware has a multiplexer to give the extra channels
3811 19:57 < sam_moore> And then we are sticking another multiplexer on that
3812 19:57 < jtanx> :P
3813 19:57 < sam_moore> But I suppose if it means we don't need 4 of the same amplifier that's nice
3814 20:03 < jtanx> ok well the pintest page works good enough
3815 20:04 < jtanx> some race conditions
3816 20:04 < jtanx> but eh
3817 20:04 < jtanx> who cares
3818 20:04 < jtanx> ohhh I know what's slowing down the bb
3819 20:04 < jtanx> bbb*
3820 20:04 < jtanx> the crazy high sampling rate
3821 20:04 < jtanx> the test files also constantly eat up all the space on my 1gb sd card
3822 20:06 < jtanx> ..or maybe not
3823 20:55 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3824 20:57 < sam_moore> It turns out UWA uses LDAP to keep track of what units you're enrolled in
3825 20:57 < sam_moore> That's interesting...
3826 20:58 < sam_moore> Potentially we could restrict access to people enrolled in MXTC3420
3827 20:58 < sam_moore> That would mess with the new courses :P
3828 20:59 < sam_moore> And it appears you can connect to ldap.pheme.uwa.edu.au from UWA's network
3829 20:59 < sam_moore> But... it also appears to use the unsecured LDAP port?
3830 20:59 < sam_moore> Surely not
3831 20:59 -!- MctxBot [[email protected]] has quit [EOF From client]
3832 20:59 < jtanx> what
3833 21:00 < sam_moore> Or maybe (hopefully) they are doing TLS
3834 21:00 < sam_moore> http://wiki.wireshark.org/LDAP
3835 21:00 < jtanx> one would hope that there's some sort of encryption going on
3836 21:00 < sam_moore> Well, there's HTTPS on the SSO page
3837 21:01 < sam_moore> But if there isn't actually encryption on the ldap connection
3838 21:01 < sam_moore> You could just plug into a switch and do some packet sniffing and get everyone's passwords :O
3839 21:01 < jtanx> haha wow
3840 21:02 < sam_moore> I think they might be using TLS, because my test program doesn't work
3841 21:02 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
3842 21:07 < sam_moore> ... Or I'm just deleting one more character than I should be in the password -_
3843 21:11 < sam_moore> Test program works now
3844 21:11 < sam_moore> Either the ldap library kindly handles TLS for you automagically, or they aren't using it
3845 21:12 < jtanx> :S
3846 21:12 < jtanx> if you used wireshark wouldn't it show whether or not it's encrypted
3847 21:16 < sam_moore> I've just run it through wireshark
3848 21:16 < sam_moore> It's not encrypted
3849 21:17 < sam_moore> My password for pheme appears plain as day
3850 21:17 < jtanx> well that sounds dodgy as hell
3851 21:18 < sam_moore> Well, you do have to have root access to a machine that can pick up the traffic
3852 21:18 < sam_moore> But yes, that sounds dodgy
3853 21:18 < sam_moore> Hang, on a minute
3854 21:18 < sam_moore> What about Unifi
3855 21:19 < sam_moore> Well...
3856 21:19 < sam_moore> I think this should be filed under "Not our problem"
3857 21:20 < jtanx> ._.
3858 21:21 < sam_moore> Surely there's some kind of handshake encryption on Unifi though
3859 21:22 < sam_moore> Anyway, I have a test function that returns true if you can login to pheme, so if we integrate that with our code and maybe modify it to look at enrolled units, that's a good start
3860 21:23 < sam_moore> Actually I also need to make it work without using deprecated functions
3861 21:25 < sam_moore> At least the library maintainers still keep the deprecated functions, but it's annoying when something that works perfectly fine and has tonnes of documentation is replaced by something that has almost no documentation
3862 21:25 < sam_moore> Almost like the new UWA courses...
3863 21:25 < jtanx> hahaha
3864 21:25 < jtanx> what's worse is where the new function is a PITA to use by design
3865 21:26 < sam_moore> Yes
3866 21:27 < sam_moore> The "deprecated" version has "LDAP * ld = ldap_init(host, port); ldap_set_options(ld, LDAP_OPT_PROTOCOL_VERSION, &version); and ldap_bind_s(ld, dn, password, authentication_method);"
3867 21:27 < sam_moore> That makes perfect sense to me
3868 21:27 < sam_moore> No doubt the new and improved version takes 100x as much code
3869 21:28 -!- Rowan [[email protected]] has quit [EOF From client]
3870 21:28 < sam_moore> Although admittedly I was confused as to why the ldap_set_options required a pointer to the integer instead of just passing the integer
3871 21:28 < sam_moore> It probably modifies it in some cases though
3872 21:31 < jtanx> which package installs ldap
3873 21:31 < sam_moore> libldap2-dev
3874 21:31 < jtanx> thanks
3875 21:31 < sam_moore> For development libraries
3876 21:32 < sam_moore> ldap-utils for tools like ldapsearch
3877 21:32 < sam_moore> At the moment I can only find documentation for libldap-dev (the deprecated stuff)
3878 21:32 < sam_moore> To get it to work, you just put a #define LDAP_DEPRECATED 1 before the #include <ldap.h>
3879 21:33 < jtanx> http://man.devl.cz/deb/l/libldap2-dev ?
3880 21:33 < sam_moore> Oh, well there you go
3881 21:33 < sam_moore> Thanks
3882 21:34 < sam_moore> No wait, it has all those functions the compiler was complaining about
3883 21:34 < sam_moore> ?
3884 21:34 < jtanx> ok then
3885 21:34 < sam_moore> Except there's this fsfuncLDAP instead of LDAP
3886 21:36 < sam_moore> ...
3887 21:36 < jtanx> oh that documentaiton is so terrible: http://www.openldap.org/doc/
3888 21:37 < jtanx> the html version is at least
3889 21:37 < sam_moore> Yeah
3890 21:38 < sam_moore> Um... given that the only documentation for libldap2 documents the "deprecated" functions, I'm going to continue using those functions
3891 21:39 < sam_moore> Installing libldap2-dev installed all those man pages
3892 21:39 < jtanx> yep
3893 21:39 < jtanx> >.>
3894 21:41 < jtanx> ldap_init(3) was obsoleted by ldap_initialize(3)
3895 21:41 < jtanx> http://www.openldap.org/lists/openldap-bugs/200509/msg00151.html
3896 21:42 < sam_moore> Seriously
3897 21:43 < sam_moore> Please tell me they changed more than just the name...
3898 21:44 < sam_moore> Oh great, they did, now I need to work out how to use it
3899 21:44 < jtanx>        int ldap_initialize(ldp, uri)
3900 21:44 < jtanx>        LDAP **ldp;
3901 21:44 < jtanx>        char *uri;
3902 21:44 < jtanx> wow, that's old school way of specifying the type of the input arguments
3903 21:45 < jtanx> I've only seen that style once elsewhere
3904 21:45 < jtanx> In code from the ~1990s
3905 21:45 < sam_moore> LDAP was invented in the 80s
3906 21:45 < sam_moore> So that would make sense
3907 21:45 < jtanx> you'd think they'd update the manpages by now though
3908 21:46 < sam_moore> They don't even note in the man page that ldap_init is depreated
3909 21:46 < jtanx> yeah
3910 21:46 < jtanx> the joys of poor documentation
3911 21:46 < sam_moore> At least the function names make sense
3912 21:46 < sam_moore> initialize
3913 21:47 < sam_moore> Obvious what that does
3914 21:47 < sam_moore> ... I think the "uri" includes the port
3915 21:47 < sam_moore> Like "ldap://server" or "ldaps://server"
3916 21:47 < jtanx> yep
3917 21:48 < jtanx> the whole ldap_init vs ldap_initialize reminds me of fopen vs fopen_s on windows
3918 21:48 < sam_moore> That's going to screw with anyone that puts their ldap server on a non-standard port for security-by-obscurity reasons
3919 21:48 < jtanx> couldn't you do
3920 21:48 < jtanx> ldap://server:port
3921 21:48 < sam_moore> Oh
3922 21:48 < sam_moore> Probably
3923 21:56 < sam_moore> Sigh... they deprecated ldap_bind and made ldap_simple_bind and then at some point that got deprecated too
3924 21:57 < sam_moore> Now it's ldap_sasl_bind_s
3925 21:57 < jtanx> what's with that naming convention
3926 21:57 < sam_moore> sasl stands for something
3927 21:57 < jtanx> _s for secure
3928 21:57 < jtanx> yey
3929 21:57 < sam_moore> The LDAP expert at UCC was basically like "It's terrible, no one ever uses it, but the LDAP standards wanted to put it in, so it's there"
3930 21:57 < sam_moore> And that's all I know
3931 21:58 < jtanx> gee ok
3932 21:59 < sam_moore> But as opposed to ldap_simple_bind(ld, dn, password)
3933 21:59 < sam_moore> You have something like 10 arguments?
3934 21:59 < sam_moore> Please let half of them be NULL...
3935 22:12 < jtanx> that's all for today
3936 22:12 < jtanx> bye
3937 22:12 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3938 23:07 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3939 23:19 < sam_moore> Hi Rowan
3940 23:19 < Rowan> hello
3941 23:19 < sam_moore> I'm working on getting logins with UWA's pheme system
3942 23:19 < sam_moore> So it will be kind of like LMS
3943 23:24 < Rowan> are we trying to keep the gui to only a few pages or can we use several.
3944 23:25 < Rowan> like a cover page(a link to just the stream, a link to dump data and a login). then the login page goes to the experiment page
3945 23:26 < sam_moore> I think several pages
3946 23:26 < sam_moore> Probably even one page per sensor?
3947 23:26 < Rowan> sweet, i shall enjoy this gui :)
3948 23:41 < sam_moore> See you tomorrow
3949 23:47 < Rowan> yep
3950 --- Day changed Mon Sep 30 2013
3951 03:31 -!- Rowan [[email protected]] has quit [Ping timeout]
3952 10:57 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3953 11:10 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3954 11:17 < sam_moore> Hi Rowan, do you have anything we should put in the report?
3955 11:34 -!- Rowan [[email protected]] has quit [Ping timeout]
3956 11:58 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3957 11:59 < Rowan> ill have the outline of all the pages i wanted on git this afternoon
3958 12:05 < sam_moore> Ok
3959 12:42 -!- Rowan [[email protected]] has quit [Connection reset by peer]
3960 12:44 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3961 13:33 < Rowan> so far i have a cover page which links to a login page which links to the index page. but theres no styles for them and no security on the login
3962 14:09 < Rowan> im not sure the files ive added went into sams git. im pretty sure they all forked over to mine. :S
3963 14:58 -!- Rowan [[email protected]] has quit [Ping timeout]
3964 15:20 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3965 15:57 -!- Rowan [[email protected]] has quit [Ping timeout]
3966 16:18 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3967 16:18 -!- jtanx [[email protected]] has quit [Ping timeout]
3968 16:31 -!- Rowan [[email protected]] has quit [EOF From client]
3969 18:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3970 18:55 -!- MctxBot [[email protected]] has quit [Ping timeout]
3971 21:18 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
3972 21:44 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
3973 22:06 -!- Rowan [[email protected]] has quit [EOF From client]
3974 --- Day changed Tue Oct 01 2013
3975 08:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3976 09:03 -!- jtanx [[email protected]] has quit ["brb"]
3977 11:04 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
3978 13:40 < sam_moore> Another option for the login system (a really terrible option that I don't condone on any real world system, but it might just get us marks)
3979 13:40 < sam_moore> Is to provide some cgi scripts that wrap around "useradd" "userdel" and "usermod"
3980 13:40 < sam_moore> And have our "Login" function check /etc/shadow
3981 13:41 < sam_moore> I emailed UWA IT help desk about Pheme anyway
3982 13:41 < sam_moore> I wonder what they'll make of it...
3983 13:51 < jtanx> hehe
3984 13:52 < sam_moore> The more I think about it, the more I think LDAP is the way you'd do this properly though
3985 13:52 < sam_moore> It basically is a text file
3986 13:53 < jtanx> yeah
3987 13:53 < sam_moore> If you started with a text file, you'd quickly find yourself reinventing the wheel and probably converging with what LDAP already does
3988 13:53 < jtanx> I guess the real problem is that rolling our own solution is not really feasible in the time left, especially if you want to ensure it's at least ok in terms of security
3989 13:57 < sam_moore> Yes
3990 14:08 < sam_moore> For reference: http://www.debuntu.org/how-to-set-up-a-ldap-server-and-its-clients/
3991 14:09 < sam_moore> And http://mindref.blogspot.com.au/2010/12/openldap-create-user.html
3992 14:09 < sam_moore> (How to set up our own LDAP server)
3993 14:11 < jtanx> slapd
3994 14:12 < jtanx> what a weird choice of a name
3995 14:12 < sam_moore> Haha
3996 14:15 < jtanx> oh 
3997 14:15 < jtanx> if you set up an ldap server
3998 14:15 < jtanx> http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page
3999 14:15 < jtanx> get them to manage the ldap database themselves
4000 14:15 < jtanx> :P
4001 14:15 < jtanx> to add or remove users
4002 14:22 < sam_moore> Yeah, that's kind of how ldap was designed
4003 14:22 < sam_moore> Technically I can probably modify my UWA "pheme" password from a command line using ldappasswd
4004 14:22 < sam_moore> Unless they use kerberos
4005 14:23 < sam_moore> (We don't want to start going into kerberos...)
4006 14:54 < sam_moore> Welp, I've put an LDAP server on my laptop for testing purposes
4007 14:54 < sam_moore> With an account "snoopy"
4008 14:55 < sam_moore> Seems to work... now to test it with our software
4009 14:55 < sam_moore> Hey, maybe we could just put an LDAP server on the BeagleBone and get a GUI LDAP editor
4010 14:56 < sam_moore> Oh right, you suggested that at 14:15
4011 14:56 < sam_moore> I like it though
4012 14:58 < jtanx> yah not too bad
4013 14:58 < jtanx> say we had an ldap server on the bbb
4014 14:59 < jtanx> we could even write the password manager in a different language
4015 14:59 < jtanx> if we wanted to make one
4016 14:59 < sam_moore> Yeah, exactly
4017 14:59 < jtanx> because it only has to interact with the ldap database
4018 14:59 < sam_moore> We shouldn't do that in the FastCGI program
4019 14:59 < jtanx> yup
4020 15:00 < sam_moore> I sent an email about it to everyone, suggesting PHP or python CGI to wrap around LDAP
4021 15:01 < sam_moore> I wonder when this system is going to start being put together though
4022 15:02 < sam_moore> We'll end up with a server and no hardware to control
4023 15:02 < jtanx> Looks like it
4024 15:02 < sam_moore> Those images Justin sent us look nice
4025 15:02 < jtanx> Yeah they look quite good
4026 15:07 < sam_moore> With the FastCGI program
4027 15:07 < sam_moore> Do you think it's better to pass options through the command line
4028 15:07 < sam_moore> Or have a bunch of #defines that need to get configured?
4029 15:08 < sam_moore> eg: To specify the LDAP server
4030 15:08 < sam_moore> (At the moment it's just a #define)
4031 15:08 < jtanx> hmm
4032 15:08 < jtanx> It's probably better to pass as a command line
4033 15:09 < sam_moore> Ok
4034 15:09 < jtanx> unless we're absolutely sure that the ldap address is fixed
4035 15:10 < sam_moore> What we can do is write a bash script that sets a bunch of variables
4036 15:10 < sam_moore> Then run.sh sources that and passes them all as arguments
4037 15:10 < jtanx> sounds good
4038 15:35 < sam_moore> What about things like the path to the GPIO and ADC? I figure they should stay as #defines
4039 15:35 < sam_moore> Since they probably won't be changing
4040 15:36 < sam_moore> At least not until the next BeagleBone kernel comes out
4041 15:36 < jtanx> hehe
4042 15:36 < jtanx> yeah that should stay as defins
4043 15:36 < jtanx> if the path does change
4044 15:36 < jtanx> then that probably warrants a recompile anyway since stuff may have changed with how you access it
4045 15:36 < sam_moore> Ok, should I put all the defines that you might want to adjust on a recompile in the same place?
4046 15:37 < sam_moore> common.h?
4047 15:37 < jtanx> what defines do we have right now
4048 15:37 < jtanx> that may change
4049 15:39 < sam_moore> Nothing major, I just want it to be flexible
4050 15:39 < jtanx> hmm
4051 15:39 < jtanx> even if you did that
4052 15:39 < jtanx> if you needed to change the define
4053 15:39 < jtanx> you'd probably be looking at changing hte code anyway
4054 15:40 < sam_moore> Sure, but that doesn't mean you can't put the defines in an easy to find place
4055 15:40 < sam_moore> For example, say someone wants to recompile this for a RPi
4056 15:40 < jtanx> But for stuff like 'where's the pwm path'
4057 15:40 < sam_moore> Given the trouble we had with pwm path confusion
4058 15:41 < jtanx> I'd look in the header relevant to pin control
4059 15:41 < sam_moore> I think it's helpful to make it easy for someone to see what we're doing
4060 15:41 < sam_moore> I suppose
4061 15:42 < jtanx> ok I guess it doesn't matter if it goes in common.h or not
4062 15:42 < sam_moore> Yeah, but I think I agree with you now :P
4063 15:42 < jtanx> ( I guess this is what ./configure and configure.h are for :P )
4064 15:51 < sam_moore> Sigh...
4065 15:51 < sam_moore> I put in a #warning to generate a warning if you tried to compile the software on something that isn't the BeagleBone
4066 15:51 < sam_moore> ...
4067 15:51 < sam_moore> And the use of #warning caused a warning
4068 15:52 < sam_moore> warning: #warning is a GCC extension [enabled by default]
4069 16:05 < jtanx> :p
4070 16:08 < jtanx> because of the -pedantic flag
4071 21:13 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4072 21:23 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4073 --- Day changed Wed Oct 02 2013
4074 17:34 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
4075 21:54 -!- Rowan [[email protected]] has quit [Ping timeout]
4076 --- Day changed Thu Oct 03 2013
4077 09:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4078 09:30 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4079 09:32 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
4080 09:45 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
4081 09:47 -!- MctxBot [[email protected]] has quit [Ping timeout]
4082 10:26 -!- MctxBot_ is now known as MctxBot
4083 10:37 -!- MctxBot [[email protected]] has quit ["leaving"]
4084 10:44 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4085 10:45 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4086 10:45 < jtanx> finally
4087 11:02 -!- Rowan [[email protected]] has quit [EOF From client]
4088 12:09 < MctxBot> guh
4089 12:09 < MctxBot> crappy laptop keeps crashing
4090 12:17 -!- jtanx [[email protected]] has quit [Ping timeout]
4091 12:20 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
4092 12:20 -!- jtanx_ is now known as jtanx
4093 12:28 < jtanx> about login_handler
4094 12:28 < jtanx> The result from FCGI_ParseRequest
4095 12:28 < jtanx> for string types
4096 12:28 < jtanx> should be treated as const char*
4097 12:29 < jtanx> I guess it really doesn't matter, unless it returns an empty string
4098 12:29 < jtanx> it's also not true that user/pass would be of max length BUFSIZ
4099 12:30 < jtanx> because of how it was defined, params has a max length of BUFSIZ
4100 12:30 < jtanx> but user/pass may be anywhere in that string
4101 12:30 < jtanx> so their max length < BUFSIZ
4102 12:30 < jtanx> so the bounds check makes no sense
4103 12:31 < jtanx> (sure, it prevents an infinite loop, but by that stage, you could be writing to locations where you don't want to anyway)
4104 12:31 < jtanx> besides, FCGI_ParseRequest should guarantee that they're null terminated
4105 12:38 < jtanx> also, whitespace (>.< :P)
4106 12:38 < sam_moore> True, but this is the whole "defensive" programming thing where you assume that some future unspecified developer is going to do something stupid and you attempt to minimise the damage they can cause :P
4107 12:38 < jtanx> while (*user && isspace(*user)) user++;
4108 12:38 < jtanx> char *ptr = user;
4109 12:38 < jtanx> while (*ptr && isalnum(*ptr)) ptr++;
4110 12:38 < jtanx> *ptr = 0;
4111 12:39 < jtanx> well
4112 12:39 < jtanx> by that stage you're screwed anyway
4113 12:39 < jtanx> not much point doing something that doesn't make sense too
4114 12:39 < sam_moore> You're more screwed if your program is writing to undefined locations in an infinite loop than if it's writing to a finite number of undefined locations
4115 12:39 < jtanx> still
4116 12:39 < jtanx> at least if it's infinite
4117 12:39 < jtanx> you'll know it crashes
4118 12:40 < jtanx> actually that's hardly the case
4119 12:40 < jtanx> because it will come across a zero at some point
4120 12:40 < jtanx> more often than not
4121 12:40 < jtanx> but anyway...
4122 12:40 < jtanx> does valgrind pick that up?
4123 12:41 < sam_moore> Hah
4124 12:41 < jtanx> and to be honest, by adding the BUFSIZ check, that's implying their max length when it's actually not
4125 12:41 < jtanx> which may be confusing in itself
4126 12:41 < sam_moore> The operating system should pick up a segfault on the first invalid write anyway
4127 12:41 < jtanx> unless
4128 12:41 < jtanx> the following region is writeable too
4129 12:42 < jtanx> eg you have a struct, members follow each other
4130 12:43 < sam_moore> If you really want to remove the bounds check go ahead
4131 12:43 < sam_moore> Either way that code does what it's meant to
4132 12:43 < jtanx> ok, well yeah
4133 12:44 < jtanx> hmm
4134 12:44 < jtanx> problem
4135 12:44 < jtanx> anyone can logout the currently logged in user
4136 12:44 < jtanx> oh wait
4137 12:45 < jtanx> sorry
4138 12:48 < sam_moore> My network is being terrible so I can't say much
4139 12:48 < sam_moore> One last argument in favour of the BUFSIZ check... if someone modifies the function that "should" be guaranteed to null terminate the string and doesn't... then you fall into an infinite loop
4140 12:49 < jtanx> well that's a case of too bad
4141 12:49 < jtanx> if it infinite loops
4142 12:49 < jtanx> then it shows you've done something wrong, so it'd be a good case to check what you've done
4143 12:50 < jtanx> if you hide that with a BUFSIZ check, you may not know there's a problem until later down the track
4144 12:50 < sam_moore> If you port the code to run in a kernel module or something, it's a case of instead of getting a seg fault, you suddenly wipe out all your memory
4145 12:50 < jtanx> with a kernel module, you'd be testing it pretty rigorously in a vm, i would think :P
4146 12:51 < sam_moore> Yeah, but it pays not to assume things about the sanity of other programmers
4147 12:51 < sam_moore> That's why all that extremely irritating "public, private" stuff is used
4148 12:52 < jtanx> to be honest, I'd rather have it fail fast than come up with weird issues that may/may not happen all the time
4149 12:52 < sam_moore> Anyway, just remove the bounds check, this is getting ridiciluos
4150 13:31 < jtanx> hmmm
4151 13:31 < jtanx> if ($http_cookie ~* "id=([^;] +)(?:;|$)" ) {
4152 13:31 < jtanx>   set  $id  $1;
4153 13:31 < jtanx> }
4154 13:32 < jtanx> right now, only the control key can be sent as the one and only cookie
4155 13:38 < jtanx> we could get nginx to extract the desired cookie
4156 14:33 < jtanx> actually nah
4157 15:02 -!- MctxBot [[email protected]] has quit [Ping timeout]
4158 16:27 -!- jtanx [[email protected]] has quit [Connection reset by peer]
4159 21:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4160 21:17 < jtanx> herp derp
4161 21:17 < jtanx> was idling in mctxuwa
4162 21:17 < jtanx> not mctxuwa_softdev
4163 21:40 < jtanx> anyway...
4164 21:40 < jtanx> a (the) login/logout functionality is almost done for the gui
4165 21:40 < jtanx> to make it work, I need to add the identify module to the modules that doesn't need login
4166 21:41 < jtanx> also, maybe fields to indicate if logged in or not when ident is called + if logged in, a 'human friendly' name to display for the user
4167 22:34 < jtanx> ok
4168 22:34 < jtanx> it's just about done. It auto redirects you (via javascript) to the login page if you're logged out (and vice versa)
4169 22:34 < jtanx> this can be disabled for debugging purposes by changing mctx.debug=true in mctx.gui.js
4170 22:34 < jtanx> it works quite well, I think
4171 22:35 < jtanx> I still haven't implemented the whole 'friendly name' thing though
4172 22:35 < jtanx> (e.g the 'Welcome Joe Bloggs' with the actual user name or something)
4173 22:40 < jtanx> test at: https://mctx.us.to:8043/test/
4174 22:42 < jtanx> except now there's a logout bug grr...
4175 22:46 < jtanx> fixed
4176 23:32 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4177 --- Day changed Fri Oct 04 2013
4178 14:50 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4179 14:50 < jtanx> so i'm in uni right now
4180 14:50 < jtanx> and was playing with the webcam
4181 14:50 < jtanx> If I followed this: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=35689&p=314596
4182 14:51 < jtanx> It actually displays something and not the black image
4183 14:51 < jtanx> the problem is that it only displays maybe the top 5% of the image
4184 14:51 < jtanx> the rest is nothing
4185 14:51 < jtanx> I think the next step from here is to try compiling the latest version of the uvcvideo driver ourselves
4186 14:51 < jtanx> see if it helps
4187 14:59 < jtanx> google 'uvcvideo beaglebone issues'
4188 14:59 < jtanx> I wonder how we didn't see that before
4189 15:00 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/223368.aspx
4190 15:03 < jtanx> so many issues getting the camera to work
4191 15:03 < jtanx> https://groups.google.com/forum/#!msg/beagleboard/sgCwaP5RVUo/aFPBOk02A7IJ
4192 15:04 < jtanx> fwiw I'm not sure we'll be able to support cameras at all, at this rate
4193 15:04 < jtanx> although some seem to have success with UVC video. no idea why
4194 15:08 < jtanx> except I was testing it on angstrom 
4195 15:08 < jtanx> when i boot off the sd card, there's no modprobe and no rmmod
4196 15:08 < jtanx> tf
4197 15:08 < jtanx> wtf
4198 15:10 < jtanx> derp
4199 15:10 < jtanx> not root
4200 15:20 < jtanx> well crap, I got it working with ffmpeg
4201 15:20 < jtanx>  ffmpeg -f video4linux2 -input_format mjpeg -i /dev/video0 -vcodec copy o.mjpg
4202 15:21 < jtanx> along with the 'uvcvideo nodrop=1 timeout=5000 quriks=0x80'
4203 15:21 < jtanx> it spits out a bunch of warnings though
4204 15:26 < jtanx> ahh
4205 15:26 < jtanx> if set to rawvideo
4206 15:27 < jtanx> 640x480 is not supported
4207 15:27 < jtanx> it must be that it's such a large resolution that only mjpg is supported
4208 15:27 < jtanx> 320x240 works fine
4209 15:32 < jtanx> ah well
4210 15:32 < jtanx> that's alll for now
4211 15:32 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4212 16:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4213 21:25 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4214 22:15 < jtanx> I got user friendly names working
4215 22:15 < jtanx> 'except by user friendly I mean their usernames
4216 22:16 < jtanx> I guess for LDAP we could look up their real name? but I don't know how to do that.
4217 22:19 < sam_moore> I'm not sure how, but it can be done
4218 22:20 < sam_moore> However it's probably a fair amount of work
4219 22:20 < sam_moore> So I'd make it low priority
4220 22:20 < jtanx> yeah ok
4221 22:20 < sam_moore> Afterall, *they* know who they are
4222 22:20 < sam_moore> Good work with the camera
4223 22:20 < sam_moore> I'll be in tomorrow morning I guess
4224 22:20 < sam_moore> Working on another project now
4225 22:21 < jtanx> Yeah, the camera's still not finished though - it's really buggy and I only got it working with ffmpeg and not opencv
4226 22:21 < sam_moore> Anything is progress
4227 22:23 < sam_moore> 0/away
4228 22:24 < sam_moore> Stupid network lag
4229 23:13 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4230 --- Day changed Sat Oct 05 2013
4231 08:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4232 08:44 -!- MctxBot [[email protected]] has quit [Ping timeout]
4233 11:37 < sam_moore> Hi, I'm at Uni, but we can't access G19
4234 11:38 < sam_moore> I was hoping Rowan, Justin, James or Callum would come in though
4235 11:38 < sam_moore> But I guess I need to do more stuff for CITS3003 anyway
4236 12:18 < jtanx> Sorry, I can't make it today
4237 12:19 < jtanx> Too much crap with my CITS3242 and CITS2232 projects to deal with
4238 12:19 < sam_moore> Ok no problem
4239 13:16 < jtanx> james just posted some layout stuff via email
4240 13:17 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4241 18:06 < jtanx> now... to do some work on this gui
4242 21:15 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4243 --- Day changed Sun Oct 06 2013
4244 08:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4245 11:17 < jtanx> slight problem: http://i.imgur.com/D28SHaQ.png
4246 11:17 < jtanx> 100% cpu usage on idle
4247 11:18 < jtanx> that memory usage too doesn't look too healthy
4248 11:18 < sam_moore> Damn
4249 11:20 < jtanx> I also probably figured out why valgrind crashes with the --trace-origins option - not enough memory on my system :P
4250 11:30 < jtanx> It's probably because in read data all the cases except one have a sleep in them
4251 11:31 < sam_moore> I'd say so
4252 11:31 < sam_moore> There are like 8 threads
4253 11:31 < sam_moore> We don't need 8 threads
4254 11:39 < sam_moore> Are you in G19?
4255 11:39 < jtanx> no
4256 11:40 < sam_moore> Alright
4257 11:40 < sam_moore> I suppose I should do some work on this
4258 11:40 < sam_moore> CITS3003 is funner though
4259 11:40 < sam_moore> I'll look into the performance issues
4260 11:41 < jtanx> hehe
4261 11:42 < sam_moore> My "Incident" with UWA IS is now Moderate Priority
4262 11:42 < sam_moore> It's been assigned!
4263 11:42 < sam_moore> I suppose I should wait for this guy to email me and say "What the hell are you on about?"
4264 11:42 < sam_moore> (Re: Using Pheme)
4265 11:42 < sam_moore> They classified it as a "Request for service"
4266 11:43 < sam_moore> Which I suppose is true, except they don't really have to do anything
4267 11:43 < jtanx> o.o
4268 11:44 < jtanx> I hope it goes through
4269 11:44 < sam_moore> Yes, no one's going to do a user management system
4270 11:44 < jtanx> Yep
4271 11:44 < sam_moore> When people complain they have nothing to do though...
4272 11:44 < sam_moore> That's like a semester of work right there
4273 12:40 < sam_moore> um... that image you linked
4274 12:40 < sam_moore> That's not actually running on the BeagleBone is it?
4275 12:40 < sam_moore> Because on the BeagleBone
4276 12:40 < sam_moore> It's like 0.7%
4277 12:41 < sam_moore> Actually 0.3% CPU 1.1% memory
4278 12:50 < jtanx> no
4279 12:50 < jtanx> that's because there's a conditional #ifdef
4280 12:50 < jtanx> beaglebone to sleep
4281 12:50 < jtanx> I got that condition around the wrong way
4282 12:50 < jtanx> Initially I thought you wanted to test the absolute maximum sampling rate on the BBB
4283 12:53 < jtanx> I just updated the repo to really remove that pwm array reference
4284 12:54 < jtanx> (about the cpu) It's because of this: https://github.com/szmoore/MCTX3420/blob/master/server/sensor.c#L257
4285 12:55 < jtanx> That ifdef should be removed anyway, just put in an unconditional sleep for 0.1s
4286 12:55 < jtanx> then remove the individual sleeps from each sensor case
4287 13:17 < sam_moore> Sure
4288 13:17 < sam_moore> Light has been shed on the PWM thing
4289 13:18 < sam_moore> They are using some RC circuit which I believe averages out the PWM to give you a constant signal
4290 13:18 < sam_moore> I thought it was some kind of IC that took a PWM input
4291 13:21 < jtanx> oh ok
4292 13:22 < jtanx> yeah that's what I thought too
4293 13:22 < jtanx> so no dac I guess
4294 13:22 < jtanx> (dac ic that is)
4295 13:24 < sam_moore> I have my doubts that electronics will be able to make this custom DAC
4296 13:24 < sam_moore> And of course, no DAC means no Pressure control
4297 13:24 < sam_moore> But oh well
4298 13:24 < jtanx> ^_^
4299 13:24 < jtanx> homebrew DAC
4300 13:25 < jtanx> how will this ever be calibrated
4301 13:26 < sam_moore> We should probably include a calibration routine in software
4302 13:27 < sam_moore> I'm looking a bit more into the RT linux stuff
4303 13:27 < sam_moore> It doesn't look too crazy
4304 13:27 < sam_moore> Our program pretty much looks the same
4305 13:27 < sam_moore> With a function at initialisation to set it's priority and stuff
4306 13:27 < sam_moore> But otherwise, you just use usleep, sleep, pthreads, everything as normal
4307 13:28 < jtanx> ok
4308 13:28 < jtanx> as long as it works on the bbb I guess
4309 13:30 < sam_moore> I think I should port from gettimeofday to clock_gettime too
4310 13:35 < sam_moore> https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
4311 13:35 < sam_moore> I'll compile us a kernel and see if it works
4312 13:46 -!- Callum [[email protected]] has joined #mctxuwa_softdev
4313 14:09 < sam_moore> Yeah, it looks like RT Linux won't work on the BBB
4314 14:09 < sam_moore> Oh well
4315 14:17 < jtanx> damn
4316 15:34 < Callum> Hey guys, sorry i havent been in touch lately. done a bit of work on dilatometer but its not quite complete.  Uploaded what iv done but i got a test i tomorrow i should go study for now
4317 16:29 < jtanx> hahaha
4318 16:30 < jtanx> interactive sbd
4319 16:31 < jtanx> hmm dialatometer
4320 16:45 < jtanx> Justin's idea with the system diagram was pretty good
4321 16:55 < jtanx> test run: https://mctx.us.to:8043/test/
4322 16:55 < jtanx> no links yet
4323 16:55 < jtanx> no descriptions either
4324 16:55 < jtanx> logout when you're done
4325 16:55 < jtanx> no auth so type anything you want in login field
4326 17:24 < Callum> looks pretty good
4327 17:27 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
4328 17:44 -!- MctxBot [[email protected]] has quit ["leaving"]
4329 17:47 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4330 17:49 -!- MctxBot [[email protected]] has quit ["again"]
4331 18:12 < jtanx> I stuffed up /etc/fstab and now the root filesystem is readonly :(
4332 18:19 < jtanx> ...and I just wasted time booting off ubuntu 7.04, which doesn't support ext4...
4333 18:30 -!- Callum_ [[email protected]] has joined #mctxuwa_softdev
4334 18:42 -!- Callum [[email protected]] has quit [Ping timeout]
4335 18:43 -!- Callum_ is now known as Callum
4336 18:52 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4337 19:30 < jtanx> I've just enabled personal webspace for everyone
4338 19:30 < jtanx> check your emails for details
4339 19:35 -!- Callum [[email protected]] has quit [EOF From client]
4340 19:50 -!- Rowan [[email protected]] has quit [Ping timeout]
4341 19:52 < jtanx> :(
4342 21:11 < sam_moore> Cool
4343 21:11 < sam_moore> Sorry, I'm trying to finish CITS3003
4344 21:14 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
4345 21:25 < jtanx> Yep no problem
4346 21:38 < jtanx> nice: http://cssmenumaker.com
4347 22:09 < jtanx> weird, getting http 500 when trying to access our github repo
4348 23:16 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4349 23:27 -!- Rowan [[email protected]] has quit [EOF From client]
4350 --- Day changed Mon Oct 07 2013
4351 10:44 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
4352 12:45 -!- callum [[email protected]] has joined #mctxuwa_softdev
4353 12:47 < callum> you guys in g19?
4354 14:46 -!- callum [[email protected]] has quit [Ping timeout]
4355 14:55 -!- callum [[email protected]] has joined #mctxuwa_softdev
4356 14:59 -!- Rowan [[email protected]] has quit [Ping timeout]
4357 16:11 -!- callum [[email protected]] has quit [Ping timeout]
4358 18:22 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4359 18:44 < jtanx> ha, you can clone a wiki
4360 18:45 < jtanx> git clone https://github.com/szmoore/MCTX3420.wiki.git
4361 20:50 < sam_moore> Yeah, I know
4362 20:51 < sam_moore> I don't really think it's great to be relying on the BeagleBone to serve all these additional requirements
4363 20:51 < jtanx> Yeah, probably not
4364 20:52 < jtanx> I've just been playing around with django for my CITS2232 project
4365 20:52 < jtanx> it's like a python based cms
4366 20:53 < sam_moore> That might work
4367 20:53 < jtanx> It's actually not too bad
4368 20:53 < jtanx> but incredibly annoying to learn how to use
4369 20:53 < jtanx> it's got its own inbuilt user system
4370 20:54 < sam_moore> How could we query it from our server though?
4371 20:54 < jtanx> as in?
4372 20:54 < jtanx> you can still query directly from the browser
4373 20:54 < jtanx> from django itself
4374 20:54 < jtanx> I'm definitely sure there's a json parsing library
4375 20:55 < jtanx> (python at least should have one)
4376 20:56 < sam_moore> As in, if we want to "login"
4377 20:56 < sam_moore> How do we authenticate?
4378 20:57 < sam_moore> From within the FastCGI process
4379 20:57 < jtanx> Okay, there's two approaches I guess
4380 20:58 < jtanx> if you want to continue to use fastcgi to login I guess you could get django to figure out
4381 20:58 < jtanx> who's logged in
4382 20:58 < jtanx> If you use django's login system
4383 20:58 < jtanx> hmm
4384 21:00 < jtanx> but one thing I haven't done yet is how do you prevent concurrent access in django
4385 21:01 < jtanx> but say this:
4386 21:01 < sam_moore> I think binding to an LDAP server is pretty standard for this sort of thing
4387 21:01 < sam_moore> I think Django can even let you bind to LDAP for using it
4388 21:01 < jtanx> probably
4389 21:01 < jtanx> I think class2go was built using django
4390 21:01 < jtanx> if you've ever used that crappy website
4391 21:02 < jtanx> say for the fastcgi process we revert to
4392 21:02 < jtanx>  /api/control?lock
4393 21:02 < jtanx>  /api/control?unlock
4394 21:02 < jtanx> etc
4395 21:02 < jtanx> but /api/control is only visible to django
4396 21:02 < sam_moore> Ah, I see
4397 21:02 < sam_moore> Um...
4398 21:02 < jtanx> then django can query it
4399 21:02 < jtanx> and conditionally return the control key?
4400 21:03 < jtanx> i dunno
4401 21:03 < sam_moore> I'd be slightly nervous about adding additional systems that have to work together though
4402 21:03 < jtanx> yeah
4403 21:03 < jtanx> that's the problem
4404 21:03 < sam_moore> I mean, if it works, it's fine
4405 21:03 < sam_moore> If it breaks, suddenly anyone (or noone) can access the real underlying hardware
4406 21:03 < jtanx> Yeah
4407 21:04 < jtanx> especially if someone screws up the server config
4408 21:04 < sam_moore> I think I'd prefer to stick with the current login handler
4409 21:04 < sam_moore> There's some flexibility with how you actually do the authentication
4410 21:04 < jtanx> Sure
4411 21:06 < jtanx> I'm just thinking, how would we implement the 'admin' features
4412 21:06 < jtanx> you'd then have to have some sort of list distinguishing normal users from admins
4413 21:06 < jtanx> unless you hardcode admins?...
4414 21:07 < sam_moore> With LDAP you can store admin as a user field and check it
4415 21:08 < sam_moore> With /etc/shadow, have 2 files
4416 21:08 < sam_moore> One for admin, one for regular users
4417 21:08 < sam_moore> (When I say /etc/shadow I just mean the style of auth, not necessarily actually using *the* /etc/shadow)
4418 21:08 < sam_moore> In fact
4419 21:09 < sam_moore> We could possibly do a minimalist user management with python cgi and a custom /etc/shadow style file
4420 21:10 < jtanx> say what
4421 21:11 < jtanx> so use the python cgi to modify it
4422 21:11 < sam_moore> Yeah
4423 21:11 < jtanx> our c fastcgi to read
4424 21:11 < sam_moore> Yes
4425 21:11 < jtanx> that could work
4426 21:11 < jtanx> have a look at flask
4427 21:11 < sam_moore> It's also probably possible to easily do a lot of the things Adam wanted
4428 21:12 < jtanx> flask is like the simpler version of django
4429 21:12 < sam_moore> At least, you can get python cgi to send emails to people with a temporary password and ask them to change it
4430 21:12 < jtanx> i think I still have an example too
4431 21:15 < sam_moore> If you want and it doesn't require rewriting large parts of the FastCGI process
4432 21:15 < sam_moore> Personally I don't think I have the time
4433 21:16 < jtanx> well if it's completely separate from the fastcgi process
4434 21:16 < sam_moore> Sure
4435 21:17 < jtanx> hmm
4436 21:18 < sam_moore> Just a simple CGI script might do the job though
4437 21:18 < jtanx> yeah
4438 21:18 < jtanx> except nginx doesn't have normal cgi
4439 21:19 < sam_moore> Wat
4440 21:19 < jtanx> only fastcgi
4441 21:19 < sam_moore> Damn
4442 21:19 < sam_moore> And I guess apache2 only has normal cgi and not fastcgi?
4443 21:19 < jtanx> there may be mod_fastcgi
4444 21:19 < jtanx> but
4445 21:19 < jtanx> before we get ahead of ourselves
4446 21:20 < jtanx> okay no, nginx doesn't have fastcgi
4447 21:20 < jtanx> sorry cgi*
4448 21:20 < jtanx> we could do it in php
4449 21:21 < jtanx> urgh
4450 21:21 < sam_moore> urgh indeed...
4451 21:21 < sam_moore> I dunno
4452 21:22 < sam_moore> We *did* tell Adam that we wouldn
4453 21:22 < sam_moore> 't be able to do the user management system
4454 21:22 < jtanx> haha
4455 21:23 < sam_moore> I really think getting our program to interface with an LDAP server is reasonable
4456 21:23 < jtanx> yeah
4457 21:23 < sam_moore> Ok, I need to fix CITS3003 some more
4458 22:46 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4459 22:53 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4460 22:53 < jtanx> brainspark: we can probably use django to proxy api requests
4461 22:53 < jtanx> so it goes like this: user <-> django <-> server api
4462 22:54 < jtanx> then you don't even have to expose the server api at all
4463 22:54 < jtanx> although if I ever end up trying this I don't know
4464 22:55 < jtanx> (by expose I mean that django can conditionally pass on the results from queries to the api)
4465 22:55 < jtanx> but yeah, it's probably best to leave it how it is right now
4466 22:55 < jtanx> as I doubt I have the time to  implement this
4467 23:10 < jtanx> it would definitely add overhead too
4468 23:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4469 --- Day changed Tue Oct 08 2013
4470 18:01 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4471 19:37 -!- MctxBot [[email protected]] has quit [Ping timeout]
4472 21:16 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4473 --- Day changed Wed Oct 09 2013
4474 08:29 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4475 09:20 -!- jtanx [[email protected]] has quit [Ping timeout]
4476 09:54 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4477 10:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4478 10:55 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
4479 10:56 < jtanx_> welp the usb microscope arrived
4480 10:56 < jtanx_> it uses uvcvideo too
4481 11:07 -!- jtanx [[email protected]] has quit [Connection reset by peer]
4482 12:00 < jtanx_> shit, we have to coordinate one report across the whole cohort
4483 12:02 < sam_moore> Yeah, shit
4484 12:03 < sam_moore> This unit has not been run very well
4485 12:03 < sam_moore> Except the tutorials
4486 12:06 < sam_moore> If I still cared I
4487 12:06 < sam_moore> d try and take charge of putting the report together
4488 12:07 < sam_moore> But I know that if no one else does it we'll all pass anyway since you can't fail an entire class
4489 12:07 < sam_moore> So terrible
4490 12:07 < sam_moore> We should just start writing a chapter on the software
4491 12:09 < sam_moore> I wonder if we could use the wiki format and export it as a pdf somehow
4492 12:11 < sam_moore> https://github.com/szmoore/MCTX3420/wiki/Hardware:-Pneumatics
4493 12:11 < sam_moore> Hilarious
4494 12:41 < jtanx_> ~.~
4495 12:41 < jtanx_> our final report will be the wiki!
4496 12:42 < jtanx_> made some progress on the camera
4497 12:42 < jtanx_> lowering the resolution to 352x288
4498 12:42 < jtanx_> and it will work with openc
4499 12:42 < jtanx_> opencv
4500 12:42 < jtanx_> ffmpeg's fine with 640x480 though
4501 12:42 < jtanx_> opencv just sucks
4502 12:57 < jtanx_> good 'ol stream.html
4503 13:05 < jtanx_> those fatal checks in sensor.c are bad
4504 13:05 < jtanx_> because half the time adc reads will fail and the whole program just crashes
4505 13:07 < jtanx_> oh right I saw your email, nevermind
4506 13:08 < jtanx_> I'm not getting the warnings that you're seeing either
4507 13:12 < sam_moore> Yeah, those warnings were actually on my laptop though, they don't seem to appear on the BeagleBone
4508 13:12 < sam_moore> I'm redoing the sensors code a fair bit
4509 13:12 < sam_moore> You'll probably hate it :P
4510 13:12 < sam_moore> Well, it's not really redoing the structure of how they work
4511 13:13 < sam_moore> Just separating the logic of how sensors get read from all that control loop stuf
4512 13:14 < sam_moore> I'm going to keep with the "one thread per sensor" idea, because that is definitely the simplest
4513 13:16 < sam_moore> Did you tell Omid that they shouldn't assume anything about the state of the GPIO pins before the software starts?
4514 13:16 < sam_moore> Which means that if (unlikely, but I don't know what they're doing) having two pins on at once would cause a catastrophic failure...
4515 13:16 < sam_moore> By murphy's law, it will almost certainly happen
4516 13:33 -!- jtanx_ [[email protected]] has quit [Ping timeout]
4517 13:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4518 13:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4519 14:51 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4520 14:52 < jtanx> oh yah, somehow electronics ordered a non-powered usb hub
4521 14:52 < jtanx> I'm pretty sure we told them to get a powered usb hub...
4522 14:57 < sam_moore> Yep, and I remember them saying that is what they were going to get
4523 14:57 < sam_moore> Dammit, I'm stuck trying to pick the best name for something -_-
4524 14:57 < sam_moore> The worst place to be stuck
4525 15:19 < jtanx> ??
4526 15:19 < jtanx> thesaurus.com
4527 15:23 < sam_moore> Hahaha
4528 15:23 < sam_moore> I decided the thing didn't really need to exist
4529 15:23 < sam_moore> Problem solved
4530 15:24 < sam_moore> If someone who knows absolutely nothing about programming tries to add sensors to our program they will still be confused
4531 15:24 < jtanx> Hahaha
4532 15:24 < sam_moore> But I hope I've made it easier for someone who knows what they're doing
4533 15:24 < jtanx> Okay
4534 15:24 < jtanx> what were the compiler warnings that you got
4535 15:25 < sam_moore> pin_test.c:41:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
4536 15:25 < sam_moore> pin_test.c:48:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
4537 15:25 < sam_moore> More on lines 54, 128, 190,204
4538 15:25 < jtanx> weird
4539 15:25 < jtanx> I never saw any of those
4540 15:25 < sam_moore> Also I think the code I just wrote for the Strain sensors gives some as well
4541 15:25 < sam_moore> Yes, it does
4542 15:26 < jtanx> did you change GPIO_Export to use int type
4543 15:26 < jtanx> wait 
4544 15:26 < jtanx> what am I saying
4545 15:26 < sam_moore> It already uses int type?
4546 15:26 < sam_moore> But it's something like that
4547 15:26 < sam_moore> It looks like you're using unsigned char for something
4548 15:27 < sam_moore>      int gpio_num = Strain_To_GPIO(id);
4549 15:27 < sam_moore>      GPIO_Export(gpio_num);
4550 15:27 < sam_moore> Is the sort of thing that causes the warning
4551 15:27 < sam_moore> But I have "bool GPIO_Export(int pin)" in bbb_pin.c
4552 15:27 < jtanx> oh right
4553 15:27 < sam_moore> So it makes no sense
4554 15:28 < jtanx> hmm
4555 15:29 < sam_moore> Ooh
4556 15:29 < sam_moore> It must be something to do with the "stub" functions
4557 15:29 < jtanx> Is this on compilation on the BBB
4558 15:29 < sam_moore> No, BBB was fine last time I checked
4559 15:29 < jtanx> okay,w ell I'm not getting any warnings
4560 15:29 < sam_moore> Compiling on my laptop because it's faster
4561 15:30 < sam_moore> #define GPIO_Export(pin) True_Stub((void*)pin)
4562 15:30 < sam_moore> That means the int is getting cast to a void*
4563 15:30 < jtanx> yeah on my computer it's not putting out any warnings
4564 15:30 < jtanx> int to void* is fine
4565 15:30 < jtanx> anything to void* is fine
4566 15:30 < jtanx> actually
4567 15:30 < jtanx> is your system 64 bit
4568 15:30 < sam_moore> 64 bit
4569 15:31 < jtanx> yeah
4570 15:31 < sam_moore> (You still have 32 bit :P)
4571 15:31 < jtanx> well that would explain it
4572 15:31 < sam_moore> Ok, it doesn't matter
4573 15:31 < sam_moore> The stub function doesn't actually do anything with the value
4574 15:31 < jtanx> cast int to int64 or whatever it is
4575 15:32 < sam_moore> That would cause warnings on the BBB though?
4576 15:32 < jtanx> only for the stub functions
4577 15:32 < jtanx> and only for 64 bit
4578 15:32 < jtanx> more ifdefs, yay
4579 15:32 < sam_moore> ...
4580 15:32 < jtanx> or we could get rid of the stubs 
4581 15:32 < sam_moore> I'm just going to ignore the warnings
4582 15:32 < sam_moore> That could also work
4583 15:32 < sam_moore> It doesn't really matter
4584 15:32 < jtanx> and just do Wno-unsued-function or someting
4585 15:32 < jtanx> yeah, oh well
4586 15:35 < jtanx> One of the suggestions for the dilatometer was to just take a photo at the start and at the end
4587 15:35 < jtanx> then do comparison
4588 15:35 < sam_moore> Um, ok
4589 15:35 < sam_moore> If they just want 2 data points
4590 15:35 < jtanx> well
4591 15:35 < jtanx> if we can find something other than opencv
4592 15:36 < sam_moore> Ah
4593 15:36 < sam_moore> How slow is it?
4594 15:36 < jtanx> that may help, because right now opencv only plays nice with 352x288 or some other crap resolution
4595 15:36 < jtanx> it's not that it's slow
4596 15:36 < jtanx> is that it only works if the resolution is ~ 350 pixels x 2xx pixels
4597 15:37 < jtanx> ffmpeg is fine with 640x480 afaik
4598 15:37 < jtanx> it could probably do higher but haven't tested that
4599 15:38 < sam_moore> http://libccv.org/
4600 15:38 < sam_moore> Maybe
4601 15:39 < jtanx> or what if we framegrabbed with some external softare
4602 15:39 < jtanx> then used opencv to process the saved image
4603 15:39 < sam_moore> Yes, I was about to suggest that
4604 15:39 < sam_moore> I'm assuming the problem with OpenCV is that it doesn't like taking images from cameras directly of that resolution
4605 15:39 < sam_moore> And not some underlying problem with having large CvMats or something
4606 15:40 < jtanx> no idea why
4607 15:40 < jtanx> some obscure setting can probably fix it or something
4608 15:40 < jtanx> but I'm not about to trawl though opencv documentaiton now
4609 15:40 < sam_moore> Actually OpenCV works with my 640x480 webcam, so it's probably some low level arm specific problem
4610 15:40 < sam_moore> Which would probably mean that other image processing libraries would also suck
4611 15:40 < jtanx> it may be that too
4612 15:41 < jtanx> I know that with ffmpeg it was spitting warnings at 640x480
4613 15:41 < jtanx> like non-monotonically increasing timestamp
4614 15:41 < jtanx> and some other crap
4615 15:41 < jtanx> I was running guvcview though
4616 15:42 < jtanx> and it seemed to take 640x480 just fine
4617 15:42 < jtanx> it was quite slow with x-forwarding and all, but at least it worked
4618 15:44 < sam_moore> Hmm
4619 15:44 < sam_moore> I would be inclined to say that taking a bunch of data points at low resolution is probably more useful than taking 2 data points at high resolution
4620 15:45 < sam_moore> The best solution is to find some way of reading at the higher resolution though
4621 15:46 < sam_moore> ... I'm worried about what Kieran is going to produce if he writes this dilatometer algorithm
4622 15:46 < sam_moore> It's going to return an array isn't it...
4623 15:46 < sam_moore> I have no idea why
4624 15:47 < jtanx> :3
4625 15:47 < jtanx> brb ~5 mins while I relocate to a lecture theatre
4626 15:47 < sam_moore> Ok
4627 15:47 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4628 15:54 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4629 16:13 < sam_moore> Ok, this is both terrible and awesome
4630 16:13 < sam_moore> But I've written a test "sensor" that is essentially just an external program
4631 16:17 < sam_moore> So... if anyone complains about not being able to use python... they can use python
4632 16:17 < sam_moore> And they don't have to reinvent all of our FastCGI stuff
4633 16:17 < sam_moore> Although apparently that's easy in python anyway
4634 16:17 < sam_moore> It's the thought that counts
4635 16:21 < jtanx> :P
4636 16:21 < jtanx> flup
4637 16:30 < jtanx> http://zacharyvoase.com/2009/09/08/sendfile/
4638 16:30 < jtanx> this could be interesting
4639 16:31 < jtanx> replace static with our fastcgi app
4640 16:31 < jtanx> http://wiki.nginx.org/XSendfile
4641 17:00 -!- jtanx [[email protected]] has quit [Ping timeout]
4642 17:52 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4643 18:07 < jtanx> mmm feature creep
4644 18:08 < sam_moore> Meh, it was better than dealing with that switch statement
4645 18:09 < jtanx> yeah
4646 18:09 < sam_moore> Also it made it really easy to decide where to put mutexes
4647 18:10 -!- MctxBot [[email protected]] has quit [Ping timeout]
4648 18:10 < sam_moore> Given that I would have had to write a "strain.c" and do about the same amount of work anyway, I think the solution is a good one
4649 18:10 < jtanx> it kind o makes sense though
4650 18:11 < jtanx> you can't particularly generalise that much to each sensor type
4651 18:11 < jtanx> so it makes sense to separate out based on what type of sensor it is
4652 18:11 < sam_moore> Yes
4653 18:11 < sam_moore> The Piped sensor is definitely feature creep though :P
4654 18:12 < jtanx> ^-^
4655 18:12 < sam_moore> Although...
4656 18:13 < sam_moore> If we wanted to distribute the sensors with a "master slave" system
4657 18:13 < sam_moore> The code would end up looking  alot like that
4658 18:13 < sam_moore> Except with a network socket instead of a unix domain socket
4659 18:14 < sam_moore> Also I'm not sure why I called it piped given that it doesn't use a pipe
4660 18:14 < sam_moore> I suppose it sounds cooler than "uds"
4661 18:20 < jtanx> So with electronics
4662 18:20 < jtanx> the reason why they were having issues with getting the psu approved 
4663 18:20 < jtanx> was because they wanted to cut the leads and solder directly to the board
4664 18:21 < jtanx> Oliver suggested that they use extension connectors
4665 18:21 < jtanx> and cut the lead on the extension
4666 18:21 < jtanx> but why they didn't think of that first, I don't know
4667 18:37 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4668 18:45 < jtanx> now to watch this week's lecture...
4669 21:31 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4670 --- Day changed Thu Oct 10 2013
4671 08:11 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4672 09:40 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4673 13:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4674 23:04 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4675 --- Day changed Fri Oct 11 2013
4676 08:21 -!- Rowan [[email protected]] has joined #mctxuwa_softdev
4677 08:42 -!- Rowan [[email protected]] has quit [EOF From client]
4678 09:19 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4679 09:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4680 15:09 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4681 15:10 < jtanx> urgh
4682 15:10 < jtanx> burning the midnight oil trying to get my cits2232 project done
4683 15:10 < jtanx> but
4684 15:10 < jtanx> it has taught me a lot about django
4685 15:10 < jtanx> which may be of use, especially for the whole admin stuff
4686 15:11 < jtanx> one possibility is that we have two separate 'logins'
4687 15:11 < jtanx> one gains you access to the site
4688 15:11 < jtanx> one gains control over the bbb (eg the server api)
4689 15:12 < jtanx> what you could do is keep the 'bind' functionality for the api, but make it check against the django user database for credentials
4690 15:12 < jtanx> I'll look into it, if not today then probably tomorrow
4691 19:39 < sam_moore> That sounds good
4692 19:48 < sam_moore> Should we do something like this: http://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file (The accepted answer) to do with our sidebar/menu stuff
4693 19:48 < sam_moore> Although...
4694 19:48 < jtanx> well 
4695 19:48 < jtanx> if we use django it has really cool templating stuff
4696 19:48 < sam_moore> That solution is actually about as much as just copy/pasting the sidebar at the moment
4697 19:48 < jtanx> yeah
4698 19:49 < sam_moore> So Django does parts of our GUI as well as the user management system?
4699 19:49 < jtanx> Well yeah
4700 19:49 < jtanx> so django would be ui mostly
4701 19:49 < jtanx> then tack on to that our api
4702 19:49 < jtanx> which remains exactly the same
4703 19:49 < jtanx> except that it uses the django database for checking authorizaiton
4704 19:50 < jtanx> so right before you commence an experiment, you try to 'gain control' of the bbb, you resupply your login creds
4705 19:50 < sam_moore> Sure, that's a good solution, I thought django would just do user management though (rather than replace the JavaScript GUI)
4706 19:50 < jtanx> well if you do use django
4707 19:50 < jtanx> it's a good idea to change some of it, because of the templating system
4708 19:51 < jtanx> and that it can conditionally show content 
4709 19:51 < sam_moore> Ok
4710 19:51 < jtanx> some of the javascript stuff will stay though, definitely
4711 19:51 < jtanx> especially all the live update stuff
4712 19:51 < jtanx> but this is getting ahead of myself, because i'm not even sure if this will work
4713 19:51 < sam_moore> Hahaha
4714 19:52 < sam_moore> You're entering a territory where I can't help much
4715 19:52 < jtanx> yeah, well all of this 'web development' is new area for me too :P
4716 19:52 < jtanx> I'm supposed to be majoring in computation, not web tech...
4717 19:52 < sam_moore> You know more/better jQuery than me
4718 19:52 < jtanx> jquery is pretty easy to learn though
4719 19:53 < jtanx> i picked it up completely from this project
4720 19:53 < sam_moore> Well, that's one reason why we went with it, since I used it briefly for something and it wasn't too hard, and James said he'd used it before too
4721 19:54 < jtanx> Yeah
4722 19:54 < sam_moore> If you want to replace stuff with django, I'm ok with that, if it's simpler
4723 19:55 < jtanx> I'll see how it goes, hopefully it shouldn't be too hard to setup
4724 19:55 < sam_moore> It just seems silly to copy/paste this Navigation Menu into every file
4725 19:55 < jtanx> yep
4726 19:55 < sam_moore> But copy/pasting the code (stack overflow) to automatically make it is also annoying
4727 19:55 < jtanx> We can roll with the jquery soln if I don't get this working
4728 19:56 < sam_moore> Unless you could include that in the "runBeforeLoad()" ?
4729 19:56 < jtanx> can't you just have a placeholder
4730 19:56 < jtanx> and on document load, you load it?
4731 19:56 < sam_moore> Yeah
4732 19:56 < jtanx> It'll look a bit crap because you'll see it before the sidebar loads
4733 19:56 < sam_moore> Actually that's how you're doing other things
4734 19:56 < jtanx> yeah
4735 19:56 < sam_moore> But the navigation menu is hard coded html
4736 19:56 < sam_moore> I'm just reading the existing code :P
4737 19:56 < jtanx> haha
4738 19:57 < jtanx> yeah it's hardcoded - it's the easiest solution
4739 19:57 < jtanx> I've got my case study for 2402 this/next week too
4740 19:57 < sam_moore> Um... I think it's fairly easy to call load from a file
4741 19:57 < sam_moore> I'll look into that
4742 19:57 < jtanx> ok
4743 19:58 < sam_moore> The case study was reasonable, although he wanted a lot more detail from us
4744 19:58 < jtanx> what did you do?
4745 19:58 < sam_moore> Despite struggling to cram it into 4 pages
4746 19:58 < sam_moore> The pencil
4747 19:58 < sam_moore> That's a good one
4748 19:58 < jtanx> ah
4749 19:58 < sam_moore> Lots of youtube videos
4750 19:58 < jtanx> we're doing pet bottles
4751 19:58 < jtanx> there's this megafactories one on the coke plant which was prettyc ool
4752 19:58 < jtanx> but yeah the pencil one also has a lot 
4753 19:58 < jtanx> i think i saw the how its made one
4754 19:59 < jtanx> Ha
4755 19:59 < jtanx> http://wiki.nginx.org/HttpSsiModule
4756 19:59 < jtanx> if you want to get server specific
4757 19:59 < jtanx> you can do ssi
4758 19:59 < jtanx> let's not do that if possible :P
4759 20:00 < sam_moore> Wait...
4760 20:00 < sam_moore> It looks like you put html comments and they get sent to the server?
4761 20:00 < sam_moore> How is that a thing?
4762 20:00 < jtanx> <!--# include file="footer.html" -->
4763 20:00 < jtanx> nah what happens
4764 20:00 < jtanx> is the server reads the html file
4765 20:00 < jtanx> and where there's special placeholders
4766 20:00 < jtanx> it does stuff
4767 20:00 < sam_moore> Ah
4768 20:01 < sam_moore> No, do it client side
4769 20:01 < jtanx> yeah
4770 20:01 < sam_moore> There's like jQuery.load
4771 20:01 < sam_moore> I'd probably keep django for user auth to start with
4772 20:01 < sam_moore> But I think jQuery should be sufficient for the GUI
4773 20:02 < jtanx> I think if you roll with django
4774 20:02 < jtanx> you should use jQuery for all the interactive stuff
4775 20:02 < jtanx> (which you'd have to anyway)
4776 20:02 < jtanx> but you should use the templating system that django's got
4777 20:03 < sam_moore> Ok, what does django give you exactly then, I'm not quite sure what the "template" stuff is, I assume it's nothing like a C++ template
4778 20:03 < jtanx> OK
4779 20:03 < jtanx> hmm
4780 20:03 < jtanx> I'll give you access to my cits2232 repo temporarily
4781 20:03 < jtanx> so you can see
4782 20:03 < sam_moore> If it lets you easily include bits of html that's cool, but jQuery looks to be able to do that easily as well
4783 20:03 < sam_moore> Alright
4784 20:04 < jtanx> actually you know what
4785 20:04 < jtanx> i'll just post it on pastebin or something
4786 20:05 < jtanx> http://privatepaste.com/ec22ba7238
4787 20:05 < jtanx> That's the base template
4788 20:05 < jtanx> http://privatepaste.com/07499e4a19
4789 20:05 < jtanx> That's the index
4790 20:05 < jtanx> {{variable_name}} will display a variable name
4791 20:05 < jtanx> sorry, the contents of that variable
4792 20:06 < jtanx> {% %} blocks are for control
4793 20:06 < sam_moore> Hmm
4794 20:07 < jtanx> the base template got a bit out of hand for that project
4795 20:07 < sam_moore> Well, if you want to use something like that I'm ok with it
4796 20:07 < sam_moore> Although I think the thing that I was originally complaining about can be solved in jQuery :P
4797 20:08 < jtanx> yeah
4798 20:08 < sam_moore> But you should probably ask everyone else involved with the GUI for input too
4799 20:08 < jtanx> Yeah, good point
4800 20:09 < sam_moore> ... Really I didn't want to be involved with the GUI, but I kind of need to mess around with at least some basic graph stuff to work out if I need to change the server sensors/actuators api
4801 20:09 < jtanx> well let's just say that i did not envision doing the gui either
4802 20:09 < sam_moore> I'll try and keep what I do consistent with the overall style though
4803 20:09 < sam_moore> Which is how I got sidetracked complaining about copy/pasting things :P
4804 20:10 < sam_moore> I think the GUI we have so far is pretty good
4805 20:10 < jtanx> hehehe
4806 20:10 < jtanx> yeah it's not too bad
4807 20:11 < jtanx> the only thing that I wouldn't know how to do is that admin stuff
4808 20:11 < sam_moore> user admin or experiment admin?
4809 20:11 < jtanx> um
4810 20:11 < jtanx> I dunno, whatever that 'admin' functionality needs to be
4811 20:11 < jtanx> like 'access the full logs'
4812 20:11 < sam_moore> Oh, right
4813 20:12 < jtanx> unless you start implementing permissions in the api
4814 20:12 < sam_moore> Hmm, we might have to
4815 20:13 < sam_moore> It should just be an enum for the user type that gets returned/set by the authentication handler and checked for certain operations
4816 20:13 < sam_moore> But as you mentioned the other day, you don't want someone to be able to login after someone else has started an experiment and cancel it
4817 20:13 < sam_moore> Actually
4818 20:13 < sam_moore> Do you?
4819 20:13 < jtanx> admin only?
4820 20:13 < sam_moore> Exactly
4821 20:14 < jtanx> how difficult is that to do though
4822 20:14 < sam_moore> Store the username of who owns the current experiment
4823 20:14 < sam_moore> Store an enum of the user type of whoever is currently logged in
4824 20:14 < sam_moore> If someone tries to stop the experiment, unless their username matches, or they are an admin, refuse
4825 20:14 < sam_moore> There could be a safety issue there?
4826 20:15 < jtanx> the only thing is
4827 20:15 < sam_moore> If someone needs to stop the experiment but isn't an admin?
4828 20:15 < jtanx> everything's based off the control key
4829 20:15 < sam_moore> Meh... add another cookie
4830 20:15 < sam_moore> ... That escalated quickly
4831 20:15 < jtanx> you've already used the nameless cookie
4832 20:15 < jtanx> if you add another cookie
4833 20:15 < jtanx> you have to do string parsing
4834 20:15 < jtanx> and have named cookies
4835 20:16 < sam_moore> Hmmm
4836 20:16 < sam_moore> "Beyond the scope of the project" ?
4837 20:16 < jtanx> i think the format was
4838 20:16 < jtanx> key=value; key=value2
4839 20:16 < jtanx> yeah, beyond the scope :P
4840 20:16 < sam_moore> Yeah, that is ever so annoying
4841 20:16 < jtanx> let's leave it for now
4842 20:16 < jtanx> come back to it
4843 20:16 < sam_moore> Because if it were something like "key=value&key=value2" you could potentially reuse the FCGI parser
4844 20:17 < jtanx> yeah
4845 20:17 < jtanx> you could modify it
4846 20:17 < sam_moore> That would be the way to go
4847 20:17 < jtanx> generalise it
4848 20:17 < sam_moore> But it's low priority now
4849 20:17 < jtanx> yep
4850 20:17 < jtanx> wow i'm getting seriously sidetracked
4851 20:18 < jtanx> this mechatronics project is more interesting than any of my other projects though
4852 20:18 < sam_moore> Haha
4853 20:19 < sam_moore> I know what you mean
4854 20:19 < sam_moore> I want to compile a RT linux kernel on my laptop (since they have x86 versions)
4855 20:19 < sam_moore> So that I can look at how much the consistency in sample rate could theoretically improve...
4856 20:20 < sam_moore> If someone managed to port the RT linux kernel to the BeagleBone
4857 20:20 < jtanx> RT linux on your computer
4858 20:20 < jtanx> isn't that generally bad
4859 20:20 < jtanx> because RT screws up other stuff
4860 20:21 < sam_moore> Like what?
4861 20:21 < jtanx> decreased performance to meet the deadlines
4862 20:21 < sam_moore> Also, I don't have to permanently replace my existing kernel, just add another bootloader entry
4863 20:22 < sam_moore> If it screws up nginx that would be annoying though
4864 20:23 < jtanx> while you're at it, try running the bfs scheduler instead of the cfs scheduler :P
4865 20:23 < sam_moore> Maybe
4866 20:42 < sam_moore> Ok, the solution to the copy/paste is just something like $("#sidebar").load("static/sidebar.html")
4867 20:42 < sam_moore> However, whilst running this in the document.ready function on a test page works, running it in index.html appears to have no effect
4868 20:43 < sam_moore> Oh
4869 20:43 < sam_moore> I know why
4870 20:43 < sam_moore> Because runBeforeLoad is failing
4871 20:43 < sam_moore> Presumably you still want to load content like the navigation bar even if the server isn't running
4872 20:44 < sam_moore> So... there is ".done()" and ".fail()" ... is there ".either()"?
4873 20:46 < sam_moore> Ahahaha
4874 20:47 < sam_moore> Of course, there is ".always()"
4875 20:49 < sam_moore> Hmm, I wouldn't want to design any sort of large system with a language like this, but it is an interesting style
4876 20:51 < jtanx> haha
4877 20:52 < sam_moore> So, a lot of the header stuff can be moved into .html files and just jQuery.loaded, which should make things cleaner
4878 20:52 < sam_moore> I will refrain from doing that now though
4879 20:53 < jtanx> don't be too tempted to do a lot of templating with javascript
4880 20:53 < jtanx> because it will load asynchronously, stuff will look weird
4881 20:53 < jtanx> and if the js breaks
4882 20:53 < jtanx> well, your page is more screwed than before
4883 20:54 < sam_moore> Ok... but you could still potentially have at least one html file in the static directory
4884 20:54 < sam_moore> With all the header and navigation stuff
4885 20:55 < sam_moore> Just have a .fail() function!
4886 20:55 < sam_moore> That's what it's for, right :P
4887 20:56 < sam_moore> $("#thing").load("static/thing.html").fail($("#thing").html("<p> Something fucked up </p>")
4888 20:56 < sam_moore> Oh dear
4889 20:58 < jtanx> ~.~
4890 20:58 < jtanx> django here: https://mctx.us.to:8043/databases
4891 20:58 < jtanx> login with testuser:testuser
4892 20:58 < jtanx> ignore that it looks a lot like our gui
4893 20:58 < jtanx> except it doesnt work anymore
4894 21:00 < sam_moore> Well, django's used for UCC for member administration
4895 21:01 < sam_moore> Except it's entirely seperate from LDAP which we use for authentication
4896 21:01 < sam_moore> Except it's not really because it binds to LDAP for authentication :S
4897 21:01 < sam_moore> Wheels within wheels...
4898 21:02 < jtanx> ookay
4899 21:04 < sam_moore> You need LDAP for shell access
4900 21:04 < sam_moore> In fact...
4901 21:04 < sam_moore> We could potentially give pheme users shell access to the BeagleBone
4902 21:04 < sam_moore> But there's not really any point
4903 21:04 < jtanx> is that a good idea
4904 21:05 < sam_moore> No
4905 21:05 < sam_moore> It's an awful idea
4906 21:05 < sam_moore> Just saying it's possible :P
4907 21:06 < sam_moore> Someone could do this: :(){ :|:& };:
4908 21:06 < sam_moore> And break the entire thing
4909 21:08 < jtanx> is that the fork bomb
4910 21:09 < jtanx> ok the site works now
4911 21:09 < jtanx> sort of
4912 21:10 < sam_moore> 400 Bad Request
4913 21:10 < jtanx> hurr
4914 21:10 < sam_moore> I think iceweasel is being dumb and ignoring https:// ?
4915 21:10 < sam_moore> Although it was fine before
4916 21:11 < jtanx> nah probably screwed up the nginx config
4917 21:11 < sam_moore> No, it works, I just had to type the https:// instead of copy paste
4918 21:11 < sam_moore> Wierd
4919 21:11 < sam_moore> The test login doesn't work though
4920 21:11 < jtanx> testuser doesn't work for some reason
4921 21:11 < jtanx> yeah just register
4922 21:12 < sam_moore> Will it actually send an email?
4923 21:12 < jtanx> urgh
4924 21:12 < jtanx> no
4925 21:12 < sam_moore> haha
4926 21:12 < jtanx> okay no the config is still broken
4927 21:16 < sam_moore> I'll have to come back to this tomorrow
4928 21:16 < sam_moore> Bye
4929 21:17 < jtanx> ok bye
4930 23:09 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4931 --- Day changed Sat Oct 12 2013
4932 10:20 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4933 13:49 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
4934 13:49 -!- MctxBot_ [[email protected]] has joined #mctxuwa_softdev
4935 14:03 -!- jtanx [[email protected]] has quit [Ping timeout]
4936 14:05 -!- MctxBot [[email protected]] has quit [Ping timeout]
4937 14:34 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4938 14:39 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4939 14:46 -!- jtanx_ [[email protected]] has quit [Ping timeout]
4940 14:47 -!- MctxBot_ [[email protected]] has quit [Ping timeout]
4941 --- Log closed Sat Oct 12 17:39:23 2013
4942 --- Log opened Sat Oct 12 22:41:38 2013
4943 22:41 -!- matches [[email protected]] has joined #mctxuwa_softdev
4944 22:41 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
4945 22:41 -!- Irssi: Join to #mctxuwa_softdev was synced in 2 secs
4946 22:41 -!- You're now known as sam_moore
4947 --- Day changed Sun Oct 13 2013
4948 08:30 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4949 10:18 < jtanx> yeah, about the django stuff, I'm not sure if we should do that now
4950 10:18 < jtanx> two options I considered:
4951 10:19 < jtanx> if you kept the 'bind' module, but added a method to authenticate against the django database, that could work, but it's a lot of effort
4952 10:19 < jtanx> - there's two ways - one is to manually do it via interaction with the sqlite database and parsing the user string etc etc
4953 10:20 < jtanx> the other way is to call the python function from c
4954 10:20 < jtanx> I explored the 'call python from c' option and it does work, but it's quite cumbersome
4955 10:20 < jtanx> I didn't bother exploring the 'manual interaction with sqlite' because that would be even more cumbersome
4956 10:21 < jtanx> The other way, which I got working quite easily
4957 10:21 < jtanx> is to protect one of the modules with nginx
4958 10:21 < jtanx> say /api/control now becomes an 'internal' only module
4959 10:21 < jtanx> so it's not usually accessible from outside
4960 10:22 < jtanx> with django, say you got the address /databases/control
4961 10:23 < jtanx> it can send back a request with header 'X-Accel-Redirect' to /api/control
4962 10:23 < jtanx> Because it was sent by django, which is an internal application, it works
4963 10:23 < jtanx> such that /databases/control looks like /api/control to the user
4964 10:24 < jtanx> the problem with this setup is that then your api becomes entirely dependent on django to work
4965 10:24 < jtanx> I guess you could replace 'django' with any other authrorization frontend
4966 10:31 < jtanx> let's just stick with what we've got
4967 10:36 < jtanx> hahahaha and that x-accel-redirect just crashed my server after I held down f5
4968 10:36 -!- MctxBot [[email protected]] has quit [Connection reset by peer]
4969 10:39 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
4970 19:19 < jtanx> I think I'll try to get in early tomorrow to work on whatever needs to be done
4971 19:56 < jtanx> For the actuators, do you really want it to crash (Fatal) if the user supplies a step say of 0,1,40000,2?
4972 21:19 < jtanx> working on the graphs now
4973 23:29 < jtanx> ookay
4974 23:29 < jtanx> too tired to check, but I refactored it and I think it still works
4975 23:30 < jtanx> I'll just leave it in my fork for now
4976 23:30 -!- jtanx [[email protected]] has quit ["bye"]
4977 --- Day changed Mon Oct 14 2013
4978 10:03 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4979 10:03 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
4980 19:15 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
4981 19:19 < jtanx> this is stupi
4982 19:19 < jtanx> d
4983 19:19 < jtanx> flot is still the easiest to use
4984 19:20 < jtanx> chart.js can only plot a line chart, so all the data series must share the same x-axis points
4985 19:20 < jtanx> jqplot sucks
4986 19:21 < jtanx> oh well, I'll work on this some other time
4987 19:21 < jtanx> stick with flot for now
4988 19:40 < sam_moore> Re actuators: No, Fatal is probably not the correct response to an invalid user input :P
4989 19:40 < sam_moore> Re just using flot: OK
4990 19:43 < sam_moore> I think we need to do a grep -R "Fatal" and get rid of the ones that don't actually need to be Fatal
4991 19:43 < sam_moore> Which is probably most of them
4992 19:44 < sam_moore> Working on more useful user based control now
4993 19:45 < jtanx> ok
4994 19:46 < jtanx> I wonder if it's possible to selectively colour text in a textarea with javascript
4995 19:47 < sam_moore> Probably?
4996 19:47 < jtanx> I have a feeling that you'd have to surround those ones in <p> blocks
4997 19:48 < sam_moore> Hmm, but that would make them all on new paragraphs
4998 19:48 < jtanx> fine, <span>s
4999 19:48 < sam_moore> That makes sense
5000 19:48 < jtanx> but you'd probably need to surround highlighted text in some sort of <> block
5001 19:48 < jtanx> so you can style it
5002 19:48 < sam_moore> Makes sense
5003 19:48 < sam_moore> What are you going to colourise?
5004 19:49 < jtanx> say if there's a fatal message
5005 19:49 < jtanx> you colour it red?
5006 19:49 < jtanx> make it blink, 90s style
5007 19:52 < sam_moore> Hahaha
5008 19:52 < sam_moore> Sounds good
5009 19:53 < sam_moore> Colourising the labels for the graph might be useful too
5010 19:53 < sam_moore> (Possibly easier than adding labels to the flot plot?)
5011 19:53 < jtanx> hmm
5012 19:54 < jtanx> what I was thinking of doing was to use nvd3, which generates the graphs using the svg element instead of a canvas
5013 19:54 < jtanx> then you can use something like http://code.google.com/p/canvg/ to render the svg in js to a png file
5014 19:55 < sam_moore> Interesting
5015 19:55 < jtanx> no idea if it will work
5016 19:56 < sam_moore> Do you even have to render it to png? SVG is a good format for graphs
5017 19:56 < jtanx> i mean if you want to save it
5018 19:56 < jtanx> i dunno, most users will go
5019 19:56 < jtanx> what's this svg format
5020 19:56 < sam_moore> That's what I mean; can you save it as an svg?
5021 19:56 < sam_moore> Hahaha
5022 19:56 < jtanx> probably
5023 19:56 < sam_moore> If it were me, I would *want* the svg format
5024 19:56 < sam_moore> You can edit the graph in inkscape
5025 19:57 < sam_moore> Really easily
5026 19:57 < jtanx> yeah
5027 19:57 < jtanx> I'd prefer the svg format too
5028 19:57 < sam_moore> Get SVG working and if you really want, add a radio box to choose the file format
5029 19:57 < jtanx> yep
5030 19:58 < sam_moore> I thought FCGI_LockControl was being called on any user action, but it looks like it's only called in login.c now
5031 19:58 < sam_moore> Is that the change you were talking about earlier?
5032 19:59 < jtanx> nah
5033 19:59 < jtanx> fcgi_lockcontrol should only be called in login.c
5034 19:59 < jtanx> there was this leftover part in control.c
5035 19:59 < sam_moore> Oh, right, nevermind
5036 19:59 < jtanx> that called it too
5037 20:00 < sam_moore> I was thinking of FCGI_HasControl,that's ok
5038 20:00 < jtanx> yeah
5039 20:10 < MctxBot> .
5040 20:12 < sam_moore> ?
5041 20:12 < sam_moore> MctxBot: Have you become sentient yet?
5042 20:12 < jtanx> I was just testing notification on all messages for chatzilla
5043 20:14 < sam_moore> Ok
5044 20:53 < sam_moore> I think the correct way to do this is to store more stuff in the FCGI_Context
5045 20:54 < sam_moore> Like the name of the experiment currently being conducted
5046 20:54 < jtanx> hmm
5047 20:54 < sam_moore> I noticed that control.c avoids storing the actual name of the experiment anywhere
5048 20:54 < sam_moore> But it's late and I'm just going to hack something together
5049 20:55 < jtanx> yeah
5050 20:55 < jtanx> I don't particularly like how 'experiments' were handled in control.c
5051 20:55 < sam_moore> g_control stores the user name of whoever last succeeded in doing an "action=start"
5052 20:55 < sam_moore> I can rework it, but not tonight
5053 20:55 < jtanx> that's fine
5054 21:41 < sam_moore> ==21160==  Uninitialised value was created by a stack allocation
5055 21:41 < sam_moore> ==21160==    at 0x6A22DBE: __md5_crypt_r (md5-crypt.c:121)
5056 21:41 < sam_moore> :S
5057 21:41 < jtanx> .....
5058 21:41 < sam_moore> Not causing an error, but still
5059 21:41 < jtanx> what does that even mean
5060 21:42 < sam_moore> It's nice to know that the linux crypt functions that are used for parsing /etc/shadow have uninitialised values
5061 21:42 < jtanx> you sure you're calling it correctly
5062 21:42 < jtanx> ?
5063 21:42 < sam_moore> The full text (brace for impact)
5064 21:42 < sam_moore> ==21160== Conditional jump or move depends on uninitialised value(s)
5065 21:42 < sam_moore> ==21160==    at 0x6D75188: ??? (strcpy.S:98)
5066 21:42 < sam_moore> ==21160==    by 0x6A230E7: __md5_crypt_r (md5-crypt.c:249)
5067 21:42 < sam_moore> ==21160==    by 0x40A5F6: Login_Shadow (login.c:93)
5068 21:42 < sam_moore> ==21160==    by 0x40AA7B: Login_Handler (login.c:243)
5069 21:42 < sam_moore> ==21160==    by 0x404CE3: FCGI_RequestLoop (fastcgi.c:548)
5070 21:42 < sam_moore> ==21160==    by 0x4052AE: main (main.c:143)
5071 21:42 < sam_moore> ==21160==  Uninitialised value was created by a stack allocation
5072 21:42 < sam_moore> ==21160==    at 0x6A22DBE: __md5_crypt_r (md5-crypt.c:121)
5073 21:42 < sam_moore> if (strcmp(crypt(pass, salt), buffer+passwd_index) == 0)
5074 21:43 < sam_moore> Looks like the correct usage to me
5075 21:43 < sam_moore> I mean, it's *working*
5076 21:43 < jtanx> ~.~
5077 21:43 < jtanx> well then
5078 21:44 < sam_moore> It's probably someone being lazy with initialising things
5079 21:44 < jtanx> https://bugzilla.redhat.com/show_bug.cgi?id=760262
5080 21:44 < sam_moore> GCC under linux usually initialises things to zero
5081 21:44 < jtanx> https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=699917
5082 21:44 < sam_moore> But under other things (like Mac OSX) it doesn't; if it's not initialised you can't assume anything
5083 21:45 < jtanx> I thought C standard was any global variables were zeroed
5084 21:45 < jtanx> anything else is undefined
5085 21:45 < sam_moore> Well it's probably not a global variable then
5086 21:45 < sam_moore> But I think you're right
5087 21:45 < sam_moore> I just remember in CITS1210
5088 21:45 < jtanx> from the bug report - 'This is an annoying, but harmless false positive warning.'
5089 21:46 < sam_moore> We had a bunch of variables that weren't initialised
5090 21:46 < sam_moore> gcc under debian/ubuntu was zeroing them for us
5091 21:46 < sam_moore> So things still worked
5092 21:46 < jtanx> yeah
5093 21:46 < sam_moore> Go to the Mac lab...
5094 21:46 < sam_moore> Everything exploded
5095 21:46 < jtanx> hahahaha
5096 21:46 < jtanx> ah... CITS1210
5097 21:46 < jtanx> when did you take it?
5098 21:46 < sam_moore> Aaages ago
5099 21:46 < sam_moore> 2009?
5100 21:47 < jtanx> that was long ago
5101 21:47 < sam_moore> Yes
5102 21:47 < jtanx> 2011 for me
5103 21:47 < sam_moore> We got 100% though :)
5104 21:47 < sam_moore> For the second project
5105 21:47 < jtanx> sweet
5106 21:47 < jtanx> I think I got that too
5107 21:47 < jtanx> they docked marks off the first one for some stupid reason 
5108 21:47 < sam_moore> (He had an infinite loop in the sample solution, which we found and eliminated in our solution, I think that was the main reason)
5109 21:48 < jtanx> ook
5110 21:48 < sam_moore> (He probably didn't appreciate the #ifdef BE_REALLY_STUPID // Replicate the behaviour *exactly* as requested by the lecturer)
5111 21:48 < jtanx> :P
5112 21:48 < sam_moore> Good fun
5113 21:49 < jtanx> yeah, one of the comments on mine was 'did not exactly match whitespace of output'
5114 21:49 < sam_moore> Haha, it was pretty harsh with the replicating exactly
5115 21:49 < sam_moore> We had a long debate about whether we should replicate the infinite loop or not
5116 21:49 < sam_moore> I think we actually submitted it with "BE_REALLY_STUPID" defined :S
5117 21:50 < jtanx> hahahaha
5118 22:24 < jtanx> now to look into nvd3
5119 22:36 < sam_moore> I've pushed some progress, I will try and clean it up later this week (it's pretty hacky)
5120 22:36 < jtanx> cool
5121 22:37 < sam_moore> I do like the idea of having svg plots, if it works it will be much nicer than flot
5122 22:37 < jtanx> hopefully
5123 22:37 < jtanx> it doesn't work in ie8 without this compat library
5124 22:37 < sam_moore> Ah
5125 22:37 < jtanx> and with compat it'll probably be slow
5126 22:37 < jtanx> but oh well
5127 22:38 < sam_moore> Fallback to flot if browser is ie8? :P
5128 22:38 < jtanx> yeah
5129 22:38 < jtanx> maybe
5130 22:38 < jtanx> that could work
5131 22:39 < sam_moore> I'm pretty sure it's within our rights to say "You need to use one of these browsers" since it's so easy to install browsers
5132 22:39 < jtanx> true
5133 22:39 < jtanx> ie8 is more an afterthought anyway
5134 22:39 < sam_moore> But I suppose if they have some stupid SOE that only includes ie6...
5135 22:39 < jtanx> if you use ie6 you'd be screwed anyway
5136 22:39 < sam_moore> Haha
5137 22:40 < sam_moore> The first flot page I made didn't work in my phone's browser, but that's probably a JavaScript setTimeout thing
5138 22:40 < jtanx> do browsers even support the canvas element
5139 22:40 < jtanx> *mobile browsers
5140 22:41 < sam_moore> Well it showed the first set of data but didn't update
5141 22:41 < jtanx> oh 
5142 22:41 < jtanx> right
5143 22:41 < sam_moore> Don't worry, we don't need to support phone browsers
5144 22:41 < sam_moore> Or at least, until we tell Adrian that we don't support phone browsers, we won't have to support phone browsers :P
5145 22:42 < jtanx> hehehe
5146 23:12 -!- jtanx [[email protected]] has quit [Connection reset by peer]
5147 23:13 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5148 23:20 < jtanx> hahaha nvd3 crashed firefox
5149 23:20 < jtanx> let me try again
5150 23:20 < jtanx> if I disconnect, you know why
5151 23:22 < jtanx> well it didn't crash, but it didn't work
5152 23:22 < jtanx> oh well, I'll try again tomorrow
5153 23:22 -!- jtanx [[email protected]] has quit ["bye"]
5154 --- Day changed Tue Oct 15 2013
5155 12:08 < sam_moore> http://jayrambhia.com/blog/capture-v4l2/
5156 12:08 < sam_moore> Might be useful?
5157 12:08 < sam_moore> I suspect the issue with the cameras is related to the colour format
5158 12:08 < sam_moore> MJPEG fails, but YUVU (whatever the hell that is) succeeds
5159 12:09 < sam_moore> Although it is still only giving 320x240
5160 12:13 < sam_moore> I noticed uvccapture, etc are quite buggy on my own debian laptop
5161 12:13 < sam_moore> I'm hoping that it might actually be a shitty userspace error that we can fix by using the v4l2 API directly
5162 12:13 < sam_moore> Although it's not likely
5163 12:14 < sam_moore> May as well try
5164 12:14 < sam_moore> But uvccapture just likes to hang forever
5165 12:14 < sam_moore> If you give it larger resolutions
5166 18:52 -!- james__ [[email protected]] has joined #mctxuwa_softdev
5167 19:29 -!- james__ [[email protected]] has quit [Ping timeout]
5168 21:27 -!- James__ [[email protected]] has joined #mctxuwa_softdev
5169 21:31 < James__> Hey Sam
5170 21:39 < James__> Having Issues uploading to the GUI to git but i have successfully tested it on Firefox, Chrome and IE.  I will continue trying to upload but if i can't i will see if i can find you or Jeremy tomorrow 
5171 21:57 -!- James__ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
5172 --- Day changed Wed Oct 16 2013
5173 13:39 -!- MctxBot [[email protected]] has quit [Ping timeout]
5174 13:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5175 13:59 < jtanx> ...
5176 13:59 < jtanx> I brought the bbb home
5177 14:00 < jtanx> booted it off an ubuntu image, and uvccapture can take 800x600 images fine from my webcap
5178 14:00 < jtanx> webcam*
5179 14:00 < jtanx> I don't know if it's because it's a different camera, or because it's a different os
5180 14:34 < jtanx> I just tested with the api/image and I can get 800x600 fine
5181 14:34 < jtanx> too
5182 14:38 < jtanx> I can even do 1600x1200 images just fine 
5183 14:38 < jtanx> ................
5184 14:38 < jtanx> ._.
5185 14:38 < jtanx> I'll be bringing this in tomorrow, see if it works with the cameras that we're going to be using
5186 14:39 < jtanx> Since my 1gb sd card was not big enough to opencv, I've actually flashed the internal memory with ubuntu
5187 14:39 < jtanx> (so I could install opencv)
5188 14:41 < jtanx> wowthat is so stupid
5189 14:42 < jtanx> so either it's the cameras that we bought, or the os 
5190 14:42 < jtanx> but it works at 1600x1200
5191 14:42 < jtanx> (max resolution of my webcam)
5192 14:43 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
5193 15:00 < jtanx> ok, I just tried it with the os we've been running before (on your 32gb sd card), and it also works at 1600x1200
5194 15:00 < jtanx> so it's an issue with the camera
5195 15:01 < jtanx> (e.g selecting a camera that actually works with the BBB
5196 15:14 -!- jtanx [[email protected]] has quit ["brb"]
5197 15:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5198 20:10 -!- MctxBot [[email protected]] has quit [Ping timeout]
5199 21:41 -!- jtanx_ [[email protected]] has joined #mctxuwa_softdev
5200 21:56 -!- jtanx [[email protected]] has quit [Ping timeout]
5201 23:28 -!- jtanx_ [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
5202 23:28 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
5203 --- Day changed Thu Oct 17 2013
5204 09:16 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5205 09:17 < jtanx> ....
5206 09:17 < jtanx> I just ran the bBB with ubuntu and used the usb microscope
5207 09:17 < jtanx> and it worked
5208 09:18 < jtanx> and so too does it work on the original os
5209 09:18 < jtanx> wtf
5210 09:33 < jtanx> hahahaa 
5211 09:33 < jtanx> it crashed because it ran out of memory 
5212 09:33 < jtanx> I tried having both cameras at once
5213 09:33 < jtanx> and switching between them 
5214 09:34 < jtanx> but other than that it works
5215 09:34 < jtanx> this is weird
5216 09:44 < jtanx> about 1/5 tries fails at 1600x1200 with 'select timeout'
5217 09:44 < jtanx> probably because it can't buffer that fast or something
5218 09:45 < jtanx> but definitely to run both cameras at once (or at least have them connected), you require an external power source, either for the beaglebone or for the usb hub
5219 09:47 < jtanx> yep
5220 09:47 < jtanx> if you do
5221 09:47 < jtanx> modprobe uvcvideo nodrop=1
5222 09:47 < jtanx> It will only display part of the image
5223 09:47 < jtanx> probably because it hasn't filled the buffer yet
5224 09:48 < jtanx> but if you load uvcvideo with normal settings
5225 09:48 < jtanx> it either displays the full image, or no image at all
5226 09:48 < jtanx> the problem is, I don't know how you detect this in opencv
5227 10:10 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
5228 13:47 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5229 14:55 -!- MctxBot [[email protected]] has quit [Ping timeout]
5230 17:14 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
5231 17:20 -!- MctxBot [[email protected]] has quit ["leaving"]
5232 17:22 -!- MctxBot [[email protected]] has joined #mctxuwa_softdev
5233 22:38 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
5234 --- Log closed Fri Oct 18 11:45:55 2013
5235 --- Log opened Fri Oct 18 11:46:19 2013
5236 11:46 -!- sam_moor1 [[email protected]] has joined #mctxuwa_softdev
5237 11:46 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
5238 11:46 -!- Irssi: Join to #mctxuwa_softdev was synced in 8 secs
5239 11:56 -!- sam_moore [[email protected]] has quit [Ping timeout]
5240 16:03 -!- You're now known as sam_moore
5241 16:03 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
5242 16:03 < sam_moore> MctxBot: Tell your master that snoopy is broken
5243 17:41 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5244 17:42 < jtanx> woops
5245 17:42 < jtanx> I probably screwed up fstab on the sd card when trying to enable swap space
5246 17:42 < jtanx> sorry about not replying earlier
5247 19:42 < sam_moore> Haha
5248 19:42 < jtanx> ~.~
5249 19:42 < sam_moore> We used ubuntu to test the pressure sensor and microphone
5250 19:42 < jtanx> what were you doing with the BBB?
5251 19:42 < jtanx> oh 
5252 19:42 < jtanx> how did that go?
5253 19:43 < sam_moore> Alright, flot and/or JavaScript suck at large numbers of points though
5254 19:43 < jtanx> yeah
5255 19:43 < jtanx> did you finally get your hands on a voltage divider or something
5256 19:44 < jtanx> or hsa the electronics team finished their stuff
5257 19:44 < sam_moore> We just made one, but electronics does have one
5258 19:45 < sam_moore> "We have 2 boards and 2 of them don't work"
5259 19:45 < sam_moore> GPIO can't trigger the relays it would seem
5260 19:45 < jtanx> well
5261 19:46 < jtanx> what are they going to do about that
5262 19:46 < sam_moore> Although we only tested 2 outputs, apparently some are 4mA some are 6mA and the thing needs 5mA
5263 19:47 < sam_moore> I don't know? Try every single pin, actually measure the current drawn by the relay switch
5264 19:47 < sam_moore> Replace the transistors on the relay
5265 19:47 < jtanx> haha
5266 19:47 < jtanx> that sounds so dodge
5267 19:47 < sam_moore> We tried 2 GPIO pins at once :S
5268 19:47 < jtanx> in parallel?
5269 19:47 < sam_moore> Didn't work
5270 19:48 < sam_moore> Yeah
5271 19:48 < jtanx> hahaha
5272 19:48 < sam_moore> But I think that might cause one to draw current from the other
5273 19:48 < jtanx> hmm
5274 19:49 < sam_moore> Need to actually look at the GPIO circuit diagram to work out what that would do
5275 19:49 < sam_moore> Our software can sample more than fast enough for the microphone
5276 19:50 < jtanx> that's cool
5277 19:50 < jtanx> could you see it on the graph
5278 19:50 < sam_moore> But plotting it in flot crashes the browser
5279 19:50 < sam_moore> Sort of
5280 19:50 < sam_moore> Had to change start_time to get all the points
5281 19:51 < jtanx> Flot doesn't sound too reliable
5282 19:51 < sam_moore> It crashes after ~1s
5283 19:51 < sam_moore> min
5284 19:51 < sam_moore> not second
5285 19:51 < jtanx> But can we just cut down on the number of data points
5286 19:51 < jtanx> how many datapoints is that after 1 min
5287 19:51 < sam_moore> It's obviously incredibly inefficient
5288 19:52 < sam_moore> I will see if averaging points helps flot
5289 19:52 < sam_moore> Or if it's actually JavaScript not liking really big arrays
5290 19:52 < jtanx> yeah
5291 19:52 < jtanx> I think having large arrays consumes an enormous amount of memory in js, for some reason
5292 19:53 < sam_moore> Dammit
5293 19:54 < sam_moore> We could make a python GUI using requests and pyplot :P
5294 19:54 < jtanx> -.-
5295 19:54 < jtanx> wouldn't it be worse, trying to plot it on the beaglebone
5296 19:55 < jtanx> given that you're using a full blown computer to plot it
5297 19:55 < sam_moore> No, you still plot it on the client
5298 19:55 < jtanx> How does that work
5299 19:56 < jtanx> You'd have to render it on the BBB, no?
5300 19:56 < sam_moore> Nope; get data the same way through HTTP and plot on the client
5301 19:56 < jtanx> what's the difference?
5302 19:57 < sam_moore> The BBB doesn't gave a problem transferring data points
5303 19:58 < sam_moore> The browser ie JavaScript sucks at coping with them
5304 19:58 < jtanx> Yeah, but if you say plot on the client, how do you plot on the client?
5305 19:58 < jtanx> ohhhhhhh
5306 19:58 < jtanx> Right I understand now
5307 19:59 < sam_moore> Python has modules for plotting
5308 19:59 < sam_moore> And modules for HTTP requests
5309 19:59 < jtanx> You're saying instead of a web interface a python gui instead
5310 19:59 < sam_moore> Maybe
5311 19:59 < jtanx> ??
5312 19:59 < sam_moore> I can at least do a proof of concept
5313 19:59 < jtanx> I'm lost 
5314 20:00 < sam_moore> But we probably shouldn't redesign the entire GUI...
5315 20:00 < jtanx> Hey, I'm all for it if it can be done
5316 20:20 < jtanx> Now, to do this control page
5317 20:20 < jtanx> A username can only contain alphanumeric characters
5318 20:21 < jtanx> right?
5319 20:21 < sam_moore> Yep
5320 20:21 < jtanx> okay
5321 20:21 < jtanx> was just thinking if someone had say .. in their username...
5322 20:25 < sam_moore> You can allow other characters
5323 20:25 < jtanx> well as in
5324 20:25 < sam_moore> Not '=' though
5325 20:25 < jtanx> having .. in their username would move you up a directory
5326 20:26 < sam_moore> Ah, cunning
5327 20:26 < sam_moore> Thwarted by general paranoia though
5328 20:26 < jtanx> :P
5329 20:26 < sam_moore> No stupid characters in usernames
5330 20:27 < sam_moore> Definitely no '/' allowed
5331 20:27 < jtanx> hahaha
5332 20:27 < jtanx> I think an alphanumeric limitation is good
5333 20:27 < jtanx> until the university stipulates having random characters in usernames
5334 20:28 < sam_moore> You forget that if the university does that they will have to cope with the same kind of bullshit
5335 20:29 < jtanx> Yeah, true that
5336 21:42 < sam_moore> I pushed a python plotting thing, but I don't really think we should be switching to it at this stage.
5337 21:42 < jtanx> Okay
5338 21:42 < sam_moore> I'll try tweak the flot GUI tomorrow to make it less shit
5339 21:43 < jtanx> hahaha
5340 21:58 < jtanx> urgh
5341 21:58 < jtanx> barely started on the control page
5342 21:59 < jtanx> I guess I'll have to complete it tomorrow
5343 21:59 < jtanx> even though we're probably (maybe) going with james gui
5344 22:00 < jtanx> I've removed the width restriction 
5345 22:00 < jtanx> and you can hide the navigation bar
5346 22:00 < jtanx> for more space
5347 22:11 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
5348 --- Day changed Sat Oct 19 2013
5349 07:59 -!- jtanx [[email protected]] has joined #mctxuwa_softdev
5350 10:39 < jtanx> blegh, now to start on the js for the control page
5351 11:10 < jtanx> what would you say if instead of all this chdir business
5352 11:10 < jtanx> one of the initial options to start the software is to specify where you want experiments to be held
5353 11:11 < jtanx> e.g /usr/share/experiments or whatever
5354 11:11 < jtanx> then you build the path based on the username
5355 11:25 < sam_moore> That sounds good
5356 11:26 < jtanx> Okay, I'll try to do that then
5357 14:37 < sam_moore> There's some kind of error in mctx.gui.js now
5358 14:37 < jtanx> what's happening?
5359 14:37 < sam_moore> A syntax error
5360 14:37 < jtanx> let me check
5361 14:38 < jtanx> what page is this on?
5362 14:38 < sam_moore> Line 272 (mctx.gui.js): outdiv[0].scrollHeight - outdiv.height()
5363 14:38 < sam_moore> Caused by loading graph.html
5364 14:38 < jtanx> ahhhh
5365 14:38 < jtanx> I know why
5366 14:38 < jtanx> maybe
5367 14:39 < jtanx> I decided to just to $("#errorlog").seterrorlog in mctx.gui.js
5368 14:39 < jtanx> so I don't have to repeat that on every page
5369 14:39 < sam_moore> The debug function also causes some error in chromium
5370 14:39 < jtanx> but if the page deosn't have an error log
5371 14:39 < jtanx> hahaha
5372 14:39 < jtanx> chromium
5373 14:39 < jtanx> what does it say
5374 14:39 < sam_moore> Didn't I tell you that something was causing iceweasel to segfault? I have no choice! :(
5375 14:40 < jtanx> :P
5376 14:40 < sam_moore> console.log.apply(this, arguments); causes an uncaught type error: illegal invocation
5377 14:40 < sam_moore> I shall replace it with "alert"
5378 14:40 < jtanx> hmm
5379 14:41 < jtanx> it's because chrome has a different implementation of console.log
5380 14:41 < jtanx> http://stackoverflow.com/questions/9521921/why-does-console-log-apply-throw-an-illegal-invocation-error
5381 14:41 < jtanx> for that bug
5382 14:41 < sam_moore> Right
5383 14:42 < sam_moore> Why is the call to outdiv.scrollTop on line 272 spread over 3 lines?
5384 14:42 < sam_moore> ... That's probably why it syntax errors
5385 14:42 < jtanx> nah
5386 14:42 < jtanx> it's legit
5387 14:43 < jtanx> the problem is there's no div there if you don't define #errorlog somewhere in your html
5388 14:43 < sam_moore> I thought the html was supposed to load any elements specific to that page
5389 14:44 < sam_moore> Which should avoid this sort of thing happening
5390 14:44 < jtanx> Yeah, except that we were repeating the same sort of load code
5391 14:44 < jtanx> in most of the pages
5392 14:44 < jtanx> I've just added a check in seterrorlog
5393 14:44 < jtanx> which should ignore if there's no such div anyway
5394 14:44 < sam_moore> ok
5395 14:44 < jtanx> that whole 'experiment dir' thing is ~.~
5396 14:44 < jtanx> I think it's mostly done
5397 14:45 < sam_moore> Ok
5398 14:45 < jtanx> so
5399 14:45 < jtanx> instead of having a file 'name.exp'
5400 14:45 < sam_moore> Yeah that was hacky
5401 14:45 < jtanx> it's a folder 'name.exp'
5402 14:45 < jtanx> all the stuff for one experiment gets stuck in that folder
5403 14:45 < sam_moore> That's slightly less hacky
5404 14:45 < jtanx> so you have something like
5405 14:45 < sam_moore> Makes sense
5406 14:46 < jtanx>  /experiments_folder/username/experiment_name.exp
5407 14:46 < sam_moore> Cool
5408 14:46 < sam_moore> If it ever is changed to use local user accounts you can just set experiments_folder to /home
5409 14:47 < jtanx> yeah
5410 14:47 < jtanx> experiments_folder is just an argument you pass to it when you start it
5411 14:47 < jtanx> -e experiment_folder
5412 14:49 < sam_moore> Found a syntax error in graph.html now
5413 14:49 < jtanx> just pushing stuff now
5414 14:49 < jtanx> but what's the errro?
5415 14:50 < sam_moore> There's an unterminated bracket on the runBeforeLoad.done
5416 14:50 < sam_moore> I think
5417 14:50 < jtanx> ah
5418 14:50 < sam_moore> So many brackets
5419 14:50 < jtanx> hehehe
5420 14:50 < jtanx> yeah you're probably right
5421 14:50 < jtanx> netbeans is giving angry red on the bracket
5422 14:51 < jtanx> do you want me to push the fix for that?
5423 14:51 < sam_moore> Well there are other issues with the page
5424 14:52 < sam_moore> No method "always" where it's being chained on the document.ready
5425 14:53 < jtanx> no wait
5426 14:53 < sam_moore> Wait what the hell is it meant to do there
5427 14:53 < jtanx> [14:52:32.186] ReferenceError: mctx is not defined @ http://localhost:8383/MCTXWeb/static/mctx.graph.js:8
5428 14:53 < jtanx> hmm
5429 14:53 < jtanx> I broke something 
5430 14:53 < sam_moore> That's not the problem I'm getting, but generally there are lots of wierd things here
5431 14:53 < jtanx> yeah
5432 14:53 < jtanx> sorry
5433 14:53 < jtanx> it was probably working before I pushed changes yesterday
5434 14:54 < sam_moore> You have runBeforeLoad.done() calling $(document).ready which does nothing, but is chained to .always which will then call $(document).ready which then loads $("#graph-controls").setDevices()
5435 14:55 < sam_moore> ... I think what I originally had was runBeforeLoad.always() calling $("#graph-controls").setDevices
5436 14:55 < sam_moore> Possibly inside a document.ready
5437 14:55 < sam_moore> But now mctx.gui.js is calling document.ready itself...
5438 14:55 < jtanx> waiit
5439 14:55 < jtanx> I think it's ok now
5440 14:56 < jtanx> it was just brackets
5441 14:56 < jtanx> I'll try it on my server first
5442 14:58 < jtanx> yeah, I see what you mean
5443 15:01 < jtanx> ahh
5444 15:01 < sam_moore> Well I fixed it enough to test stuff
5445 15:01 < jtanx> yeah
5446 15:02 < jtanx> you planning on modifying stuff?
5447 15:02 < sam_moore> I think it's just a matter of having runBeforeLoad().done() call $(document).ready() and then initialise stuff
5448 15:02 < jtanx> I'll just keep it in my repo for now
5449 15:03 < sam_moore> With runBeforeLoad.fail if you want to handle bad stuff
5450 15:03 < jtanx> I just made it
5451 15:03 < jtanx> runBeforeLoad().always(function() {
5452 15:03 < jtanx>         $(document).ready(function() {
5453 15:03 < jtanx>           $("#graph-controls").setDevices();
5454 15:03 < jtanx>         });
5455 15:03 < jtanx>       });
5456 15:03 < sam_moore> Yep, that's what I just did
5457 15:03 < sam_moore> You can commit it and I'll pull it
5458 15:03 < jtanx> okay
5459 15:03 < sam_moore> If you fix the console and the errorlog things as well
5460 15:03 < jtanx> yep
5461 15:03 < jtanx> pushed that too
5462 15:05 < sam_moore> Hmm, start_time = -1 is not actually giving the most recent second of data
5463 15:05 < sam_moore> That might be a server API problem
5464 15:05 < jtanx> hmmm
5465 15:05 < sam_moore> But it might also explain why things were shitting themselves so much with the fast sampling rate
5466 15:06 < jtanx> what is it giving?
5467 15:06 < sam_moore> Because the jQuery would be getting hundreds of thousands of points...
5468 15:07 < sam_moore> At the moment the server API is not giving any points and giving back a stupid value for start_time
5469 15:07 < sam_moore> I think I might have broken it when I changed all the clocks
5470 15:07 < jtanx> when did you change ti?
5471 15:07 < sam_moore> Just now
5472 15:07 < jtanx> ah
5473 15:07 < sam_moore> I'm hoping that my first assumption about the thousands of points was the case before I broke it as well :P
5474 15:08 < sam_moore> (ie: It was already broken before I broke it more)
5475 15:08 < jtanx> ahahahah
5476 15:08 < jtanx> I can try
5477 15:08 < jtanx> I still have the old version
5478 15:09 < jtanx> with start_time=-1 it returns nothing
5479 15:09 < jtanx> start_time in the response is constant
5480 15:11 < sam_moore> Yeah I get wierd stuff
5481 15:11 < sam_moore> start_time = 17889.590701
5482 15:12 < sam_moore> "current_time" : 18589.539255
5483 15:12 < jtanx> is that with clock_gettime?
5484 15:12 < sam_moore> "running_time" : 699.948554,
5485 15:12 < sam_moore> Yes
5486 15:13 < sam_moore> Oh herdurp
5487 15:13 < sam_moore> start_time in the JSON response is *not* the same as start_time the parameter to the sensor
5488 15:13 < jtanx> yeah
5489 15:13 < sam_moore> .... should probably change that
5490 15:13 < jtanx> start time of experiment
5491 15:14 < jtanx> experiment_start_time?
5492 15:14 < jtanx> long variable names...
5493 15:14 < sam_moore> I think it's actually the program start time
5494 15:14 < jtanx> nup
5495 15:14 < jtanx> experiment starttime
5496 15:14 < sam_moore> Alright
5497 15:14 < jtanx> oh
5498 15:14 < jtanx> actually you may be right
5499 15:14 < sam_moore> Haha
5500 15:14 < jtanx> I thought i changed it
5501 15:14 < jtanx> wway back when i did the control stuff
5502 15:15 < jtanx> initially
5503 15:15 < sam_moore> ControlData has a start_time variable
5504 15:15 < jtanx> yeah
5505 15:15 < sam_moore> But g_options has a start_time variable
5506 15:15 < sam_moore> -_-
5507 15:15 < jtanx> that's confusing
5508 15:15 < jtanx> hahaha
5509 15:15 < sam_moore> Yeah, what idiot designed this...
5510 15:15 < jtanx> ~.~`
5511 15:19 < sam_moore> Right, sensor values are being saved relative to Control_GetStartTime (experiment starting time)
5512 15:19 < sam_moore> That's fine
5513 15:19 < jtanx> yep
5514 15:19 < sam_moore> Sensor_Handler gets "current_time" from that as well
5515 15:19 < jtanx> Thread safety on that is dodgey
5516 15:19 < jtanx> I must say
5517 15:20 < jtanx> but it's probably fine
5518 15:20 < sam_moore> It's fine, clock_gettime is posix thread safe
5519 15:21 < sam_moore> Oh, do you mean if the experiment changes
5520 15:21 < jtanx> yeah
5521 15:21 < jtanx> the whole *Control_GetStartTime() looks dodgy too
5522 15:22 < sam_moore> Perhaps just a "double Control_CurrentTime()" would be better
5523 15:22 < sam_moore> But it works
5524 15:22 < jtanx> hmm
5525 15:24 < sam_moore> Anyway, I think start_time=-1 is not giving any data because the default sampling rate is 1s and therefore current_time - 1 is outside the data range most of the time
5526 15:25 < sam_moore> start_time=-3 gives a single point with the default sampling rate
5527 15:25 < sam_moore> Increasing the sampling rate then you appear to get the right points
5528 15:31 < sam_moore> I'm going to repeat my timestamp test with the current software under regular kernel and RT linux
5529 15:32 < sam_moore> I know we can't ever get RT linux but I want to see if it makes much of a difference
5530 15:46 < jtanx> okay
5531 15:50 < jtanx> finally... back to actually coding the control page
5532 22:59 -!- jtanx [[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]

UCC git Repository :: git.ucc.asn.au