20:49 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
22:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Wed Aug 14 2013
+09:13 < jtanx> I've done a version using fastcgi, which was surprisingly quite easy to set up
+09:13 < jtanx> see here: https://github.com/jtanx/MCTX3420/tree/master/testing/fastcgi-approach
+10:41 < sam_moore> That looks interesting, I'd prefer that to the PHP/database solution
+10:42 < sam_moore> My concern is: You have to query the web server to start the process, even though it keeps running
+10:42 < sam_moore> Also, I know "write a custom HTTP server" sounds scary, but it does actually work
+10:43 < jtanx> nah
+10:43 < jtanx> fastcgi
+10:43 < jtanx> the process is started once and always runs
+10:43 < jtanx> so you have a request loop
+10:44 < jtanx> wait
+10:44 < jtanx> how do you envision it working?
+10:45 < sam_moore> Oh, right, I see how the fastcgi approach would work, it's basically the same idea; you have something responding to HTTP queries in one thread, something dealing with sensors/actuators in seperate threads
+10:45 < jtanx> yeah
+10:46 < jtanx> except that you don't have to worry about maintaining your own webserver
+10:46 < sam_moore> Cool
+10:46 < sam_moore> I do think that the HTTP server isn't that hard, and it's mostly working
+10:46 < sam_moore> But we can probably switch to fastcgi
+10:48 < sam_moore> I mean, we still have to parse a query string right?
+10:48 < jtanx> well yes
+10:48 < jtanx> if your request was
+10:48 < jtanx> http://blah/cgi/?key=value&anotherkey=value2
+10:48 < jtanx> you'd get back key=value&anotherkey=value2
+10:48 < jtanx> as query string
+10:50 < jtanx> try it out here: http://124.169.120.181:8080/cgi
+10:51 < jtanx> (hopefully that forwards ok)
+10:51 < sam_moore> Yep, that's cool
+10:51 < sam_moore> The HTTP server I wrote basically does that
+10:51 < sam_moore> But if it really bothers you, I'm fine with switching to fastcgi :P
+10:52 < jtanx> well whatever works
+10:52 < jtanx> but I thought it might be more maintainable if you used something that already exists :P
+10:52 < sam_moore> Yeah, but thinking about it, what maintainence does the HTTP server require?
+10:53 < sam_moore> Oh well, it's a good idea
+10:53 < jtanx> for this situation not much
+10:57 < sam_moore> We can pretty easily start with a structure that would allow us to switch, but I'd lean towards keeping the custom HTTP server
+10:58 < sam_moore> Have you done multithreading in C before?
+10:58 < jtanx> in windows yes
+10:58 < jtanx> on linux not really
+10:58 < sam_moore> Ah, I've only done it on linux
+10:58 < jtanx> i did a bit in operating systems
+10:59 < jtanx> but kinda forgot
+10:59 < sam_moore> It shouldn't be too hard for our purposes
+11:00 < jtanx> that thing with running a custom webserver is that if anyone wants to reuse this in the future, i doubt they'd really like the idea of that
+11:01 < jtanx> say they had some new fangled thing that requires php
+11:01 < jtanx> which isn't going to work
+11:01 < jtanx> but with a standard webserver like apache or nginx, it's really easy to just install an extra addon
+11:02 < sam_moore> I suppose... what would they need the new fangled php thing for?
+11:03 < jtanx> well that's the thing - for now I don't know, but it could be required
+11:03 < sam_moore> Yeah, good point
+11:03 < sam_moore> Ok, another reason to use an existing web server, is we might require some advanced features if we want to be serious about the safety stuff
+11:04 < sam_moore> For example, it would be a fair amount of work to add SSL to make the custom thing do https
+11:04 < jtanx> oh yeah
+11:04 < jtanx> that too
+11:04 < sam_moore> Also we might want some authentication on it
+11:04 < jtanx> nginx/apache are highly customisable
+11:05 < sam_moore> I've never used nginx, what are it'
+11:05 < sam_moore> s advantages over apache2?
+11:05 < jtanx> nginx
+11:05 < jtanx> yup
+11:05 < jtanx> its really good
+11:05 < sam_moore> Haha
+11:05 < jtanx> a lot of sites use it because it's fast
+11:05 < sam_moore> Fast is good
+11:05 < jtanx> faster than apache
+11:05 < sam_moore> Sold
+11:05 < sam_moore> Well, we only need one user as well
+11:05 < sam_moore> In fact, we deliberately do not want to have multiple clients able to use the thing at the same time
+11:05 < jtanx> haha true
+11:07 < sam_moore> Ok, so I think you've convinced me to use fastcgi
+11:07 < sam_moore> Most of the custom HTTP server was reused code, so I didn't waste too much time on it
+11:07 < jtanx> haha ok
+11:07 < jtanx> have you written one before?
+11:09 < sam_moore> Not specifically a HTTP server, but I've written a project for posix systems with a fair bit of networking
+11:09 < sam_moore> git.ucc.asn.au/?p=matches/swarm.git
+11:10 < jtanx> nice
+11:10 < sam_moore> It allows you to run a shell, eg: bash accross multiple machines at once
+11:11 < sam_moore> Not as useful as I thought it might be, but it was fun
+11:12 < jtanx> heh
+11:12 < jtanx> what did you end up using it for?
+11:13 < sam_moore> I was setting up a programming competition where you have AIs play against each other
+11:13 < sam_moore> I wanted to make a round robin
+11:13 < sam_moore> So I had a bash script setup to do that, but then I got impatient, because it would have to run the games in order
+11:14 < jtanx> oO
+11:14 < sam_moore> Well it turned out no one entered the competition, so I probably didn't need to go overboard
+11:14 < sam_moore> But maybe I can use it for something else
+11:15 < sam_moore> For the threading I'm thinking of using pthreads
+11:16 < sam_moore> The alternative is OpenMP, but it's more suited to numerical computation, rather than having seperate things talking to each other
+11:16 < jtanx> okay
+11:17 < sam_moore> My goal for this week was to have the framework started, so we just have some really basic threads running and then we can start implementing them
+11:17 < jtanx> yeah that would be good
+11:18 < sam_moore> If you want to do some work with the fastcgi part so that we'll be able to parse the query strings, that would probably be a good start
+11:18 < sam_moore> We don't have the exact details of pretty much anything yet
+11:18 < sam_moore> Maybe talk to James/Rowan about how the GUI is going to query the server
+11:19 < sam_moore> Also, did you see my suggested naming convention?
+11:19 < jtanx> no
+11:20 < sam_moore> I don't really mind, although I'd prefer not to have hungarian notation
+11:20 < sam_moore> As long as it'
+11:20 < sam_moore> s consistent
+11:21 < sam_moore> But the suggestion was: FunctionName, variable_name (local or member), Structure, ENUMVALUE, Extern_FunctionName, g_global
+11:21 < jtanx> okay I'll try to keep to that
+11:22 < sam_moore> Cool, I should probably go do something else
+12:33 < jtanx> i gotta go
+12:33 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+16:56 < jtanx_> a beagleboard
+16:56 < jtanx_> hmm
+16:58 -!- jtanx_ is now known as jtanx
+17:03 < jtanx> is it the beaglebone black?
+17:03 < jtanx> sounds interesting
+17:04 < sam_moore> They didn't specify
+17:04 < sam_moore> Oh right, I accidentally cut out his message
+17:04 < sam_moore> tl;dr "Beagle Board"
+17:04 < jtanx> the beagle board is around $125 though
+17:04 < sam_moore> Probably the Beaglebone black
+17:04 < sam_moore> Oh really
+17:04 < sam_moore> Heh
+17:04 < jtanx> yeah
+17:05 < jtanx> the beaglebone black is $45
+17:05 < jtanx> but just looking the A/D converter on the black has a max voltage of 1.8v
+17:05 < sam_moore> That's probably what they meant, since they said it is "not much more expensive"
+17:05 < sam_moore> That should be fine; the sensors team says things are in mV
+17:05 < jtanx> okay
+17:05 < jtanx> that's good
+17:05 < sam_moore> Really though... electronics should be asking the sensors team stuff like this
+17:06 < jtanx> heh yeah
+17:06 < sam_moore> They should probably have asked us if it was feasable for software
+17:06 < sam_moore> Maybe they had someone who knew it would be, but still
+17:06 < sam_moore> It looks like it is anyway, so crisis averted
+17:07 < jtanx> just with the sensors, I think that the diferences need to be amplified so it covers the full range of the A/D converter
+17:07 < sam_moore> Yes, the sensors guy knows that
+17:07 < jtanx> yeah so if its only 1.8v there's less range than 0-5v
+17:08 < jtanx> is that compensated enough by having a 12 bit a/d converter vs a 10 bit (i think arduino is 10 bit) converter
+17:10 < sam_moore> I think so; you get ~4x more resolution from the 12 bit ADC and lose ~3x from the lower range
+17:10 < sam_moore> Also there's no set requirement yet on what the resolution should be
+17:11 < jtanx> true
+17:11 < jtanx> well in any case the bb black sounds quite nice
+17:11 < sam_moore> Yep, it'll probably be good to use
+17:14 < sam_moore> I'm much happier now that we actually have regular verbal communication with the other teams
+18:23 < sam_moore> I'm looking into getting doxygen working for this
+18:59 < jtanx> for the documentation?
+18:59 < jtanx> seems good, but never used it before myself
+19:01 < jtanx> looks a lot like javadoc
+21:26 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:54 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Thu Aug 15 2013
+08:21 < jtanx> hey
+08:22 < jtanx> just a suggestion for the logging functions, but you can use macros
+08:22 < jtanx> to get the function name (and even file name)
+08:22 < jtanx> v
+08:22 < jtanx> http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
+08:23 < jtanx> so you can do stuff like #define Log(level, fmt, ...) LogReal(level, __func__, fmt, __VA_ARGS__)
+08:25 < jtanx> it should be c99 conformant
+09:15 < jtanx> I created a pull request anyway
+09:33 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+13:39 < sam_moore> Yeah, I probably should have looked at that
+13:46 < jtanx> back to the rpi+arduino
+13:47 < jtanx> didn't they know about the beagle board black, or can that not be used for some reason?
+13:48 < jtanx> beagle bone* black
+14:20 < sam_moore> I don't know what model they were looking at exactly
+14:20 < sam_moore> I told them the Beagle Bone was about $50, I haven't had much time to research it myself
+14:20 < sam_moore> I didn't know about the Beagle Board/Bone, which was why I suggeste the RPi + Arduino
+14:20 < sam_moore> They originally were just considering an Arduino
+14:21 < sam_moore> Which would not have been fun for the remote interfacing stuff
+14:21 < sam_moore> Well we could do it, but we wouldn't be able to have a nice web browser controlled GUI, probably some dedicated networked server/client with a GUI program installed on the client machine
+14:22 < sam_moore> Also image processing would have been interesting
+14:23 < sam_moore> Next time there's a combined groups meeting, hopefully we can talk to them more
+14:24 < jtanx> yeah
+14:24 < jtanx> there's quite a few
+14:24 < jtanx> there's a beagleboard which is ~150
+14:24 < jtanx> beaglebone which is ~90
+14:24 < jtanx> beaglebone black which is ~50
+14:24 < sam_moore> Right
+14:24 < sam_moore> So they were probably looking at the beaglebone for $90
+14:24 < jtanx> yeah probably
+14:24 < jtanx> it's weird because the black version has better specs, from what i can see
+14:25 < sam_moore> But still, even for $150, if it saves us 10 hours of writing code to interface the RPi with Arduinos, it will be worth it
+14:25 < jtanx> yeah exactly
+14:25 < sam_moore> Arduinos themselves cost a bit
+14:25 < jtanx> well
+14:25 < jtanx> you can get equivalents off ebay
+14:25 < jtanx> like an uno is $10
+14:26 < sam_moore> The only issue with the beaglebone to avoid having to use arduinos as well, is whether it has enough ADC by itself
+14:26 < jtanx> yeah
+14:26 < jtanx> well how many sensors are needed
+14:26 < sam_moore> If it doesn't, you might have to add an Arduino or two anyway
+14:26 < jtanx> you could just add on an adc chip
+14:26 < sam_moore> Yes, or something like that
+14:27 < jtanx> the beaglebone has like a bazillion gpio ports
+14:31 < sam_moore> Well without getting into the specific details, it sounds like we should recommend they use that
+14:32 < sam_moore> Apparently the sensors team will have a list ready by monday, which will be good
+14:33 < jtanx> that'd be good
+14:35 < jtanx> when are combined group meetings? just the 9am slot?
+14:36 < sam_moore> 9am Tuesday is the "official" time picked by Adrian, 2pm Wednesday is the time that we agreed between the teams
+14:36 < sam_moore> I'm going to go to both, if more people want to come from the team that's also good
+14:37 < sam_moore> Realistically not everyone is going to come, so I'll have to send emails a lot
+14:38 < jtanx> ok
+14:39 < sam_moore> What account do you need to be invited to the dropbox?
+14:39 < sam_moore> I think Alex invited everyone using their student email
+14:40 < sam_moore> Oh right, you wouldn't have been in the list that he used if you enrolled late
+14:40 < jtanx> yeah, through student email would be good
+14:41 < jtanx> last year's experiment ran with an arduino diecimila which only had 5 analogue inputs
+14:41 < jtanx> any reason why we need more?
+14:41 < jtanx> sorry that's 6
+14:42 < sam_moore> I think the estimate was: 4-6 strain gauges, 1 temperature sensor, 1 microphone, 2 pressure gauges, 1 (maybe 2) USB webcam
+14:43 < jtanx> ok
+14:44 < jtanx> At that rate you would definitely need something with more analogue inputs
+14:45 < sam_moore> We also might need a DAC for one of the pneumatics team's devices
+14:46 < sam_moore> But you can't get that on a microcontroller, there'd have to be a seperate module
+14:46 < jtanx> yep
+14:48 < jtanx> it'd be no point interfacing an arduino to the rpi/beaglebone if all you want is more analog inputs
+14:49 < sam_moore> If you can get modules for ADC that can talk to a rpi/beaglebone, then yes
+14:49 < jtanx> yeah
+14:49 < jtanx> I don't think they're too hard to wire up
+14:50 < sam_moore> I think the electronics team should be considering all this, but I don't know since we haven't verbally spoken
+14:50 < sam_moore> Well not at length anyway
+14:51 < sam_moore> Just when I happen to bump into Omid
+14:51 < jtanx> hmm
+14:54 < sam_moore> This project is probably going to be a good lesson in "Why you need a project manager"
+14:55 < jtanx> so true
+14:59 < jtanx> with the web interface, what sort of update times are we looking at?
+15:00 < sam_moore> My tests with apache2 and the custom HTTP server showed it took about 50us for jQuery to get an AJAX request
+15:01 < sam_moore> There was only one data point returned each time though, we can probably optimise it a bit by returning multiple data points with a request
+15:01 < jtanx> yeah
+15:07 < jtanx> I wonder what sort of performance impact running one (or two) cameras would have on the rpi/beaglebone
+15:44 < jtanx> urgh
+15:45 < jtanx> I was wondering why my nginx config wasn't working
+15:45 < jtanx> until I realised that gedit was creating a backup copy of the config file
+15:45 < jtanx> so nginx was reading both the original and backup
+17:28 < sam_moore> That's wierd, you'd think it would only read one config file
+17:34 < jtanx> well it was in a config directory
+17:36 < sam_moore> Oh, ok
+18:49 < jtanx> so the current idea i have with the web thing is
+18:49 < jtanx> you can query it like http://domain/api/module?key=value&key=value2
+18:50 < jtanx> and then you could return something in json format or whatever is most suitable for the ajax query
+19:46 < jtanx> you can test it at http://mctx.us.to:8080/apoi
+19:46 < jtanx> woops, http://mctx.us.to:8080/api
+19:46 < jtanx> the only 'module' which will give a response of '200 OK' is sensors
+19:47 < jtanx> which currently spits back any arguments you pass to it
+19:47 < jtanx> eg http://mctx.us.to:8080/api/sensors?k=v
+19:50 < jtanx> hopefully it doesn't break
+20:44 < sam_moore> I'll take a look
+20:45 < sam_moore> Looks good
+20:45 < sam_moore> I'm writing a dummy thread for a sensor now
+21:04 < jtanx> the code behind it (in the cgi module) is a bit clunky right now though
+21:04 < jtanx> is there a meeting tomorrow?
+21:05 < sam_moore> I don't think so, sorry
+21:06 < jtanx> ok that's alright
+21:06 < sam_moore> Things aren't urgent (yet)
+21:07 < jtanx> heh
+21:12 < sam_moore> For the progress report: I'd like everyone to write a page individually, then we can summarize those in the group report
+21:12 < sam_moore> Well you don't have to write a whole page, and if you miss a week or so it's not a big problem
+21:16 < jtanx> ok
+21:17 < jtanx> i'll try to remember that
+21:18 < jtanx> do you think we need to keep track of how long we spend on this project
+21:18 < jtanx> for that 'cost estimate'
+21:28 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:23 < sam_moore> For the cost estimate: Yes, we are supposed to have a technical diary (hand written)
+22:23 < sam_moore> Including all notes and times worked on the project
+22:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Fri Aug 16 2013
+09:48 < jtanx> I was wondering what sort of model you have for reading/storing sensor values and controlling actuators
+10:02 < sam_moore> At the moment each sensor has a thread that continuously polls the sensor and dumps data to a binary file
+10:03 < sam_moore> For reading there is a thread that fills a buffer from the file when it gets a request
+10:04 < sam_moore> It might be better to change to a single thread for sensors/actuators though
+10:04 < jtanx> yeah, I was about to say if it was necessary to have one for each
+10:05 < sam_moore> Probably not, if you had varying polling speeds it would be useful, because you could poll the fast sensors seperately from the slow ones
+10:05 < jtanx> how do you wish to pass the data to the fcgi module?
+10:06 < jtanx> right now
+10:06 < jtanx> i've kinda set it so
+10:06 < jtanx> there's this thing called a ModuleHandler
+10:07 < jtanx> so you can pass it some data (tba what this is), and it also receives the query string from the use
+10:09 < sam_moore> Well, the ModuleHandler gets called whenever the right HTTP request is made right?
+10:10 < sam_moore> So, that function retrieves the data it needs to respond to the request
+10:10 < jtanx> well rightnow the typedef is
+10:10 < jtanx> typedef void (*ModuleHandler) (Data *data, char *params);
+10:10 < jtanx> so it's up to you to write a module handler (eg SensorsHandler)
+10:11 < sam_moore> Ok, data's a bit of an ambigous name, so is that something passed to the ModuleHandler when the FastCGI gets a request?
+10:11 < jtanx> well the data thing was a placeholder for whatever sensors/actuators data there was
+10:11 < sam_moore> Is it meant to be sensor data, or is it a value that the user has passed through HTTP
+10:11 < jtanx> the query string is part of params
+10:11 < sam_moore> Ok, right, that makes more sense
+10:12 < sam_moore> My view had the ModuleHandler getting the appropriate data itself
+10:12 < jtanx> Ok
+10:12 < sam_moore> Given the params
+10:13 < jtanx> I'm just not really used to using global variables
+10:13 < sam_moore> The global sensors array?
+10:13 < jtanx> yeah
+10:13 < jtanx> i take it that's where you access data from?
+10:14 < sam_moore> Yes
+10:14 < jtanx> oh yeah one more thing, when you get a request, should it only return the latest data?
+10:20 < sam_moore> We should probably think some more about this as a whole group
+10:20 < sam_moore> So, you have a sensor that can (probably) poll a lot faster than you get requests via jQuery
+10:21 < sam_moore> You can write it so that you only actually query the sensor when you get a request, but then you're wasting the chance to get data that could be useful
+10:22 < sam_moore> Or you can have it so that the sensor is continuously polling (What my code is simulating at the moment)
+10:22 < sam_moore> With the continuosuly polling sensor; when you get a request, you can either return the most recent block of data you got
+10:23 < sam_moore> Or you can have it so that the data will be sent in sequential order (which is what my code currently does)
+10:23 < jtanx> hmm
+10:23 < sam_moore> I'm pretty sure continously polling is better than querying each time you get a request, since after all this is an experiment and you want the data
+10:23 < jtanx> yeah
+10:24 < jtanx> I agree with you there
+10:24 < jtanx> so you're saying, continuously poll and log the results
+10:24 < jtanx> and when a request comes in, send back all the data up to the point when the last request came in
+10:25 < sam_moore> Well that's what the server program I wrote simulates at the moment.
+10:25 < sam_moore> However it might be more sensible for the request to just get the most recent data.
+10:25 < jtanx> hmm
+10:25 < sam_moore> Ah, yeah that's probably better actually
+10:25 < jtanx> then you're logging more points than youdisplay
+10:26 < sam_moore> Yes, but you can always add a function to pull all the data points and save to a csv or something like that.
+10:26 < sam_moore> In fact I think we'd want to do that.
+10:27 < jtanx> yeah ok
+10:27 < jtanx> that sounds not too bad
+10:27 < jtanx> but if that's the case
+10:27 < sam_moore> If you actually use this for an experiment, you're not going to want to have to do all your analysis in a JavaScript GUI
+10:27 < jtanx> true
+10:27 < sam_moore> The GUI is for getting live information on the state of the system more than for data analysis
+10:27 < jtanx> but if that's the case you might want to allow direct access to the latest dataset
+10:28 < jtanx> instead of having to read from the file
+10:28 < jtanx> if that's possible
+10:28 < jtanx> then you can directly record the results in csv format
+10:28 < sam_moore> Yes, I thought about that; you can have a buffer of points accessed by the request thread easily enough
+10:29 < sam_moore> There are some difficulties though with managing the buffer
+10:30 < sam_moore> Wait, maybe it's easier than I though
+10:30 < sam_moore> Yeah, the reason I started saving stuff to a binary file was because I was thinking of the requests having to get the data in sequence
+10:32 < sam_moore> I have some other stuff to do today unfortunately
+10:33 < sam_moore> I have a feeling it won't be trivial to just access the most recent dataset, I'll have to think about it
+10:34 < sam_moore> However, currently it should be easy to change so that the request gets data from the end of the binary file, rather than keeping track of its position
+10:34 < sam_moore> The function QuerySensor is what I was thinking the SensorHandler would do to get data; it just fills a buffer and prints it at the moment
+10:35 < sam_moore> Binary file access is pretty fast, we could even just keep the binary file and change the data to csv when it goes to the client
+10:36 < jtanx> ok, I'll keep that in mind
+11:11 < sam_moore> Oh, you can replace the Data* pointer with a Sensor* pointer and then not have to use the global variable directly, that's probably best
+11:13 < jtanx> well it might not only be sensor data
+11:13 < jtanx> it could be actuator stuff or anything else
+11:13 < sam_moore> I suppose
+11:14 < jtanx> maybe I should change the typedef to void*
+11:14 < jtanx> then you can cast it to whatever
+11:14 < sam_moore> Yeah, that will work
+11:15 < sam_moore> Actuator stuff is going to be a bit of a seperate (hopefully easier) problem
+11:15 < sam_moore> In that case you can just wait for a query before doing anything
+11:15 < sam_moore> Anyway, I've distracted myself again, this is just too interesting :S
+11:15 < jtanx> hahaha
+11:16 < jtanx> anycase for the actuator you would have a separate handler function
+11:16 < sam_moore> Yes
+11:16 < jtanx> eg ActuatorHandler
+11:20 < jtanx> fcgi is pretty whack
+11:20 < jtanx> it replaces printf
+11:21 < jtanx> so when you printf (or fwrite for binary?), that gets sent to the client
+12:03 < jtanx> hey
+12:04 < jtanx> what if we stored stuff in an sqlite library
+12:04 < jtanx> sorry database
+12:04 < jtanx> on second thoughts nah
+15:02 -!- jtanx_ is now known as jtanx
+18:59 -!- jtanx_ is now known as jtanx
+21:28 < sam_moore> So, I did a bit of testing with sqlite vs a binary file
+21:28 < sam_moore> sqlite takes about 1000x as long for saving data
+21:28 < sam_moore> I haven't tested reading it back yet
+21:28 < sam_moore> But more worrying
+21:28 < sam_moore> I get a segmentation fault using sqlite
+21:29 < sam_moore> And it's in the sqlite library somewhere; not my test code
+21:29 < sam_moore> Running sqlite in valgrind shows a bunch of complaints about uninitialised values
+21:29 < sam_moore> So... I'd recommend we just use a binary file
+21:30 < sam_moore> A database is good for storing more complex data, but when you just need to store data recorded in a sequence, it's probably unnecessary
+21:36 < jtanx> yeah sqlite not so good for file performance
+21:36 < jtanx> because every insert it has to confirm the write to disk
+21:36 < jtanx> the segfault
+21:36 < jtanx> may actually be because you didn't initialse the mutex
+21:36 < jtanx> es
+21:36 < jtanx> i tried compiling it on mingw and it segfaults on the mutex unlock
+21:37 < sam_moore> Re: fcgi replacing printf - It probably calls dup2 to change stdout from the terminal to a domain socket or fifo that nginx listens to
+21:37 < jtanx> nah
+21:38 < jtanx> fcgi_stdio just has a bunch of defines
+21:38 < sam_moore> Oh really, that's wierd
+21:38 < jtanx> so printf becomes FCGI_printf
+21:38 < jtanx> so fcgi_stdio must be the first include in the fcgi module
+21:38 < sam_moore> I would have thought it was simpler to just change stdout than replace the whole printf function
+21:38 < sam_moore> But whatever, we're not implementing fcgi :P
+21:38 < jtanx> haha
+21:39 < sam_moore> Oh, the mutex needs initialising, yeah
+21:39 < sam_moore> But the test I did was just a serial program, no mutex
+21:39 < jtanx> ah
+21:39 < jtanx> well
+21:39 < sam_moore> We'll be using gcc to compile on the beaglebone/rpi
+21:40 < sam_moore> I think some implementations of pthreads need an initialiser but others don't, I'll have to check
+21:40 < sam_moore> But pthread_mutex_init doesn't show up in man pages on debian
+21:40 < jtanx> yeah it's not on ubuntu either
+21:41 < jtanx> have you ever worked with clang
+21:42 < sam_moore> No
+21:42 < jtanx> neither but it seems pretty cool
+21:45 < jtanx> when you compile it gives better diagnostic output when something goes wrong
+21:46 < jtanx> it's a drop in replacement for gcc
+21:47 < sam_moore> Interesting
+21:57 < jtanx> if you kept the file handles for the sensor data always open
+21:58 < jtanx> and immediately wrote to them when a data point is polled
+21:58 < jtanx> is there much performance difference to buffering first?
+22:05 < sam_moore> Yeah, it's probably better to keep the file handles always open
+22:05 < sam_moore> The operating system will use some kind of buffer for the file anyway
+22:06 < sam_moore> I've got some basic programs, maybe I'll make some performance graphs tomorrow
+22:07 < sam_moore> On the other hand, I need to do some of the meta stuff (list of tasks that need to be completed, etc) before Monday
+22:08 < sam_moore> I should look into a #define or something to initialise the mutexes if they need to be
+22:09 < sam_moore> Anyway, I need to sleep
+22:11 < sam_moore> I wonder how James and Callum are going, they haven't been in the channel for a while
+22:12 < jtanx> yeah, it's pretty quiet
+22:17 < sam_moore> If we can get a second meeting in the week, preferably a longer one that would be good
+22:18 < sam_moore> Particularly if we can start working on code at the same time
+22:18 < sam_moore> But we'll see
+22:18 < sam_moore> Everyone has other stuff to do after all
+22:18 < sam_moore> I'm spending way too much time on this unit compared to my others
+22:18 < sam_moore> Then again this unit will probably require the most work
+22:19 < sam_moore> Anyway, bye
+22:23 < jtanx> bye
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Sat Aug 17 2013
+22:25 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Sun Aug 18 2013
+21:53 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+22:37 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
+--- Day changed Mon Aug 19 2013
+11:43 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+13:34 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+20:07 < jtanx> just so you know, I'm changing the JSON functions
+21:04 < sam_moore> Ok, I already pushed some stuff to github
+21:05 < sam_moore> But we can get it to merge
+21:05 < sam_moore> I ended up just using printf to make part of the JSON in the SensorHandler anyway
+21:06 < jtanx> depending on where SensorHandler is
+21:06 < jtanx> that may or may not work
+21:06 < jtanx> inside of fastcgi.c it willwork
+21:06 < jtanx> outside it won't
+21:07 < jtanx> oh ok
+21:07 < jtanx> I see
+21:07 < jtanx> so that's fine
+21:08 < jtanx> it might be best not to use a do while loop
+21:08 < jtanx> because if no arguments are passed
+21:08 < sam_moore> Ah, right
+21:08 < jtanx> then the keypair function will return null
+21:09 < jtanx> while ((params = FCGI_KeyPair(params, &key, &value)))
+21:09 < jtanx> will work fine
+21:10 < sam_moore> The KeyPair function looks like it can return an empty string though, in which case I was getting the sensor_id parsed twice when I was testing it
+21:10 < jtanx> what was your input string?
+21:11 < sam_moore> "http://localhost/api/sensors?id=0"
+21:11 < jtanx> looks fine from this end
+21:11 < jtanx> http://mctx.us.to:8080/api/sensors?id=0
+21:11 < jtanx> it might be because of your do while loop
+21:12 < jtanx> yeah it will be because of that
+21:12 < sam_moore> The do while loop causes problems when there is an empty string
+21:13 < sam_moore> ie: No parameters are passed
+21:13 < jtanx> ok let's just put it this way; FCGI_KeyPair was designed to use a while loop
+21:13 < sam_moore> Ok, sure
+21:13 < sam_moore> I had some problems with just a while loop, but I'll try again
+21:13 < jtanx> yeah about that JSON stuff
+21:13 < jtanx> I'm still trying to think of a good way to do that
+21:13 < jtanx> especially with the array stuff
+21:19 < sam_moore> I'm not sure what I did before, but a while loop seems ok now
+21:19 < jtanx> heh
+21:21 < sam_moore> Ok, I have to go now
+21:21 < sam_moore> I might not be able to do much tomorrow, we'll see
+21:22 < jtanx> ok yep
+21:35 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+23:14 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:35 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Aug 20 2013
+15:06 < Callum> hey same
+15:06 < Callum> sam*
+15:20 < jtanx> :>
+15:22 < Callum> he literally set himself to away as soon as i said that
+15:45 < jtanx> urgh this json stuff is doing my head in
+15:57 < sam_moore> Callum: I've been set to away since last night
+15:57 < Callum> o.O not according to my client
+15:58 < sam_moore> Anyway, we are definitely using the Beaglebone, Electronics has ordered one, they seemed to think they'd have to program it but I corrected them
+15:58 < Callum> ...why would they have to program it? wtf did they think we were doing?
+15:59 < sam_moore> They probably thought all we had to do was the GUI and not any of the other software? I don't know. But the guy seemed relieved anyway.
+15:59 < Callum> and was gonna ask if you remembered anything about the pi meson decay question for physics (how do you get the anti-neutrinos momentum, or do you assume it to be 0 as well? but then it doesnt really make sense with conservation of momentum)
+16:00 < sam_moore> Woah, I don't remember the assignments in that much detail
+16:00 < Callum> was hoping you would :p
+16:00 < sam_moore> No, I just have vague memories of algebra
+16:01 < sam_moore> And looking through notes
+16:01 < Callum> hmm. i cant seem to find anything in the notes
+16:01 < Callum> because he says to assume the rest mass of the anti-neutrino is 0
+16:02 < Callum> and i don't really remember much in regards to energies and 0 rest mass ;/
+16:02 < jtanx> I talked to someone who did computer vision before
+16:02 < jtanx> and he's really doubtful that you can get accurate readings off a webcam
+16:02 < sam_moore> Callum: I don't think you can assume the momentum is zero, other than that, I don't have much to offer
+16:02 < Callum> the question also says to have it in terms of m(pi) m(e) and c
+16:03 < Callum> and yea thats what i thought. it doesnt make sense to do that. just cant remember how to do it D;
+16:03 < Callum> @jeremy yea well, its a pain but possible
+16:04 < Callum> really comes down to how good your camera is/sampling rate/how quickly you can process it.
+16:04 < sam_moore> How about you do some experimenting with a webcam and see what you can do with it?
+16:04 < Callum> but you can get some pretty good webcams nowadays (but then again the better it is the longer it takes to process)
+16:04 < jtanx> personally, I don't think it will work
+16:04 < sam_moore> It looks like we might just end up streaming images diretly to a website
+16:04 < Callum> i don't have any
+16:04 < Callum> yea well even if thats all we do we still need the camera
+16:05 < Callum> spose i could use my laptop one but i doubt that would be very good
+16:05 < Callum> could run it through the canny algorithm and see what it produces
+16:06 < sam_moore> Sounds like an idea
+16:07 < sam_moore> A good idea specifically
+16:07 < jtanx> about the sensorhandler
+16:07 < sam_moore> Yes?
+16:07 < jtanx> do you envision leaving it in fastcgi.c permanently
+16:07 < jtanx> or for that matter any other handlers
+16:07 < sam_moore> I was kind of thinking there would be a "handlers.h" and "handlers.c"
+16:08 < sam_moore> Just to make things more organised
+16:08 < jtanx> yeah
+16:08 < jtanx> I'm trying to export enough of the functionality
+16:08 < jtanx> to do that
+16:08 < jtanx> but the json thing is annoying
+16:08 < jtanx> especially when you need to spit out arrays
+16:09 < jtanx> unless you have something like FCGI_Printf
+16:09 < jtanx> and it's up to you to format it correctly
+16:09 < Callum> bloody physics lecture video is laggy. gonna have to download it and hope for the best. fuck echo
+16:10 < jtanx> compared to lectopia you get 2x filesize with no visible benefit in quality
+16:10 < Callum> they're both shit.
+16:10 < sam_moore> You could have seperate "BuildJSON_Key" and "BuildJSON_Value" functions, with a "BuildJSON_ValueArray" maybe
+16:10 < Callum> haha
+16:11 < sam_moore> FCGI_Printf is Ok though, it's not too much formating
+16:11 < jtanx> the problem with the buildjson_* stuff
+16:11 < jtanx> is it gets very verbose
+16:12 < jtanx> and you can probably come up witha situation that breaks it too
+16:12 < jtanx> and don't get me started on value types
+16:12 < sam_moore> Haha
+16:14 < sam_moore> We can always just send plain text and make James turn it into JSON :P
+16:14 < jtanx> ahaha
+16:14 < jtanx> yeah that could work
+16:15 < jtanx> mm
+16:15 < jtanx> this is where java is good
+16:15 < jtanx> or any other higher level language
+16:21 < jtanx> ok so it's a bit of both, but how about: FCGI_JSONKey(key) and FCGI_JSONValue(format, ...)
+16:22 < sam_moore> That looks good
+16:25 < jtanx> I'm also adding long/double types for the BuildJSON function, just for convenience
+16:25 < jtanx> any preference to naming conventions?
+16:26 < jtanx> FCGI_BuildJSONLong
+16:27 < sam_moore> Seems OK
+16:28 < sam_moore> I need to go do some ENSC1001 stuff (hooray)
+16:29 < jtanx> yuck
+16:30 < Callum> hhaha
+16:30 < Callum> have fun :p
+16:30 < Callum> although i cant really talk. about a days worth of physics and a days worth of ensc3016 shit i should get through, on top of mctx and geng4402 stuff. yay for being behind already
+16:38 < Callum> well iv got an answer for the first part (second part should be the same process). just hope its right :s
+16:46 < jtanx> ok, time to merge this into the server code
+19:47 < jtanx> hmm interesting - it crashes if compiled with clang but not with gcc
+19:49 < jtanx> probably just a bug in clang 3.2
+20:08 < jtanx> ok, just submitted a pull request to update the fastcgi stuff
+20:08 < jtanx> for now I moved Sensor_Handler to sensor.c
+20:09 < jtanx> the status codes have all changed
+20:09 < jtanx> If you absolutely cannot process anything given the input arguments, you call FCGI_RejectJSON
+20:10 < jtanx> If you fail for some other reason (e.g unauthorized access), you use FCGI_BeginJSON with the appropriate status code
+20:10 < jtanx> With RejectJSON, it sends a HTTP 400 code so any query through AJAX/jQuery will fail with no extra info
+20:11 < jtanx> With BeginJSON, the HTTP code is always 200 OK, so you are able to transmit extra info if it failed for another reason
+20:12 < jtanx> BeginJSON will automatically add the module handler name + the status code
+21:47 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Wed Aug 21 2013
+11:57 < jtanx> hmm
+11:57 < jtanx> I just had a play with the sensor stuff
+11:57 < jtanx> and I trialled a 'double buffer' scheme
+11:57 < jtanx> instead of the binary file idea
+11:57 < jtanx> seems to work okay, and it guarantees that a point won't be returned to the user if they have already received it
+12:35 < jtanx> urgh
+12:35 < jtanx> just worked through some stupid bug
+12:37 < jtanx> I think it's because make didn't recompile something because it thought it hadn't changed
+12:38 < jtanx> probably the header files
+12:50 < jtanx> you can see the double buffer method in this branch: https://github.com/jtanx/MCTX3420/tree/doublebuffer
+12:58 < jtanx> one issue though is that writing out csv instead of binary file takes up a lot more space
+14:49 < james__> Hey
+14:50 -!- james__ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Thu Aug 22 2013
+13:20 < callum> hey
+15:07 < callum> sam you still at uni?
+15:22 < callum> or jeremy if you remember what he used to compile the file. i'v managed to get it to recognise the header files but now its complaining about not being able to find the libraries.
+15:34 < jtanx> um
+15:34 < jtanx> I can't remember
+15:34 < jtanx> didn't you use pkg config to find out
+15:36 < jtanx> try this http://opencv.willowgarage.com/wiki/CompileOpenCVUsingLinux
+22:08 < sam_moore> gcc -o opencv opencv.c -I/usr/include/opencv -lopencv_core -lopencv_highgui -lopencv_imgproc
+22:08 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [0 ops, 0 halfops, 0 voices, 1 normal]
+22:08 < sam_moore> Oh... there's no one here
+22:08 < sam_moore> Well, if you read the IRC logs when they're commited to git, you'll see it. Good luck.
+--- Day changed Fri Aug 23 2013
+07:49 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+08:59 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+10:12 -!- jtanx [
[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
+12:30 < jtanx_> um
+12:30 < jtanx_> do you know how you connected the relay board to the sensor board
+12:30 < jtanx_> for the soldering lab
+12:45 < jtanx_> and what sort of wire did you use?
+12:58 < jtanx_> brb
+12:58 -!- jtanx_ [
[email protected]] has quit ["http://www.mibbit.com ajax IRC Client"]
+--- Log opened Sat Aug 24 17:07:53 2013
+17:07 -!- ServerMode/#mctxuwa_softdev [+nt] by irc.eversible.com
+17:07 -!- Irssi: #mctxuwa_softdev: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
+17:07 -!- Irssi: Join to #mctxuwa_softdev was synced in 1 secs
+17:08 -!- You're now known as sam_moore
+--- Day changed Mon Aug 26 2013
+11:12 <@sam_moore> Thought I might have the wrong server
+17:18 <@sam_moore> I do have the wrong server!
+17:19 -!- sam_moore [
[email protected]] has left #mctxuwa_softdev [I have the wrong server!]
+--- Log closed Mon Aug 26 17:19:05 2013
+--- Log opened Mon Aug 26 17:19:34 2013
+17:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+17:19 -!- Irssi: Join to #mctxuwa_softdev was synced in 5 secs
+17:19 < sam_moore> !motd
+17:20 < sam_moore> '!motd'
+17:20 < sam_moore> MctxBot: You're broken
+17:20 < sam_moore> Oh wait, never mind
+18:08 < jtanx> :P
+18:09 < jtanx> you can change the message if you want
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Tue Aug 27 2013
+07:54 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+19:11 < jtanx> lol
+19:11 < jtanx> the camera that we were using for the soldering lab inserted a bunch of wavy lines/static into the video
+19:12 < sam_moore> It's an effect
+19:14 < jtanx> nah
+19:14 < jtanx> the camera was actually broken
+19:15 < sam_moore> (I figured that)
+19:15 < sam_moore> You could pretend it's supposed to be an 80s style video?
+19:15 < jtanx> yeah that could work
+19:16 < jtanx> have you done it yet?
+19:18 < sam_moore> No :S
+19:20 < jtanx> well
+19:21 < jtanx> according to the manual, you need to connect a wire from R5 on the sensor board to the relay board
+19:21 < jtanx> problem was we already chopped off the lead on R5
+19:22 < jtanx> another group connected the wire to the LEd though
+19:22 < jtanx> seemed to work
+20:02 < jtanx> so are we using clock_gettime?
+20:08 < sam_moore> I think so, we can use CLOCK_MONOTONIC_RAW if we are paranoid about the system time getting changed
+20:08 < sam_moore> Or we can just use CLOCK_REALTIME if we aren't
+20:09 < jtanx> I thought CLOCK_MONOTONIC was supposed to be best, because the RAW version wasn't compensated for temp/other stuff
+20:10 < jtanx> http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-and-clock-monotonic
+20:10 < jtanx> about the FCGI loop blocking
+20:10 < jtanx> you can switch to FCGX_ methods
+20:10 < jtanx> I think
+20:11 < jtanx> but is it really necessary
+20:20 < jtanx> about the valgrind comment in sensors.c
+20:20 < jtanx> this is probably it: http://stackoverflow.com/questions/5844242/valgrind-yells-about-an-uninitialised-bytes
+20:23 < sam_moore> It's probably not necessary to stop the FCGI loop blocking, don't worry about it
+20:25 < sam_moore> Yeah, I didn't initialise the buffers anywhere
+20:25 < jtanx> actually I can't reproduce that message
+20:25 < sam_moore> Hmm
+20:26 < jtanx> about the sensor times
+20:27 < jtanx> what about if you all reference it relative to some point
+20:27 < jtanx> eg
+20:27 < sam_moore> The epoch :P
+20:27 < jtanx> lol
+20:27 < jtanx> I mean
+20:28 < jtanx> when you get sensor data, you store the difference in time between the start of recording and now
+20:28 < sam_moore> Sure, that makes more sense
+20:29 < sam_moore> Just give the client the start of recording time and they can convert it to a time of day / day in the calendar themselves
+20:30 < jtanx> yeah
+20:30 < jtanx> you could have a specific request to return the starting time
+20:30 < jtanx> then it's implicit for all requests
+20:30 < jtanx> btw I submitted a pull request for the nginx configs
+20:32 < sam_moore> Ok
+20:32 < sam_moore> I've added you to collaborators so you can merge them yourself if you need to
+20:33 < jtanx> ok
+20:35 < jtanx> huh
+20:35 < jtanx> http://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
+20:41 < sam_moore> Nice
+20:42 < sam_moore> "Currently you can not access Ethernet" Not so nice
+20:42 < sam_moore> Although this is dated 2011
+--- Day changed Wed Aug 28 2013
+10:39 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+16:31 < jtanx> huh
+16:31 < jtanx> firefox's javascript debugger is pretty cool
+16:31 < sam_moore> Firebug? Yeah
+16:35 < jtanx> nah the inbuilt one
+16:35 < jtanx> firebug's good for inspecting html though
+16:35 < jtanx> haven't used firebugs js debugger yet
+16:35 < sam_moore> Oh, I didn't know they had an inbuilt one
+16:36 < jtanx> Ctrl+Shift+K
+16:36 < sam_moore> Of course I normally use Iceweasel, which is currently built as firefox 10.0.2 with a different name
+16:36 < jtanx> well that's about 10 releases behind
+16:36 < sam_moore> That looks pretty similar to firebug anyway
+16:55 < jtanx> inline conditionals in javascript are whack
+16:55 < sam_moore> I haven't done much javascript, but a lot of it does seem whack
+16:56 < sam_moore> jtanx: What are you working on in JavaScript?
+16:56 < jtanx> unit tests
+16:57 < sam_moore> Cool
+17:01 -!- Callum_ is now known as Callum
+17:18 < jtanx> javascript in general is annoying me though
+17:25 < Callum> when exactly is this soldering lab due? fucking thing.
+17:27 < jtanx> next friday
+17:27 < Callum> it says week 5 on lms
+17:27 < jtanx> sept 6
+17:27 < Callum> where's it say this?
+17:27 < jtanx> yeah he made an announcement
+17:27 < jtanx> that it's wrong
+17:27 < jtanx> somewhere
+17:28 < Callum> sigh. this unit..i swear
+17:28 < Callum> if it really is next week then i'd be so relieved
+17:28 < Callum> wow
+17:28 < Callum> he made an announcement today..
+17:28 < Callum> wait yesterday
+17:29 < jtanx> still got that central plant fbd to do
+17:29 < Callum> why hasnt LMS emailed me a notification? (/end spam)
+17:29 < Callum> yea i know
+17:29 < Callum> which i think i have it pretty much done
+17:29 < Callum> not 100% sure on it though
+17:29 < Callum> and whether to add pumps and shit into it
+17:29 < jtanx> what did you have on it?
+17:30 < Callum> HA as i say that i check my phone and i have the message about the announcement
+17:30 < jtanx> and what did you call the chiller things?
+17:30 < Callum> pretty much just the 4 chillers, a line showing it can go back (they're literally called chillers ahha(
+17:31 < Callum> then i had another part to show the chillers (evaporation/condensor/compressor and cooling tower is connected to condenser)
+17:31 < jtanx> ook
+17:31 < Callum> however
+17:32 < Callum> im not sure about the input/output of the chiller
+17:32 < Callum> because stuff online shows it to be the evaporator
+17:32 < Callum> but isnt it water being pumped?
+17:32 < jtanx> I think there were pumps on the output
+17:33 < jtanx> were there three outputs?
+17:33 < Callum> also not sure if i should/wherte to add the tank (yea ofc theres pumps but not sure to put them in to the diagram, pretty much everything is pumped)
+17:33 < Callum> outputs where?
+17:33 < jtanx> North/Sout/East distribution things
+17:33 < jtanx> iirc
+17:33 < jtanx> yeah not sure whether to add tank or not
+17:34 < Callum> oh that, i didnt bother with that
+17:34 < Callum> just how did the chiller connect with the rest of the plant?
+17:34 < Callum> was the evaporator the input/output?
+17:34 < Callum> because the chiller feeds out to the water tower and the tower feeds back into the chiller (i think)
+17:36 < Callum> also what was the thing called? that allowed water to flow back and forth bypassing the chillers. back something?
+17:36 < Callum> really they should have told us before we went in we had to do this. some lazy fucks like me dont read the outline so i didnt take notes..or try to commit stuff to memory :po
+17:39 < jtanx> the bypass?
+17:39 < jtanx> I haven't gone into detail
+17:39 < jtanx> so I just have chiller
+17:39 < jtanx> and cooling tower
+17:39 < jtanx> maybe I should
+17:40 < Callum> remember how tehre was 4 chillers, and they would only run what was needed.
+17:40 < jtanx> yeah
+17:40 < jtanx> how many cooling towers?
+17:40 < Callum> and if they had more than they needed there was a pipe to flow back, or if they had some chilled water from the tanks or w.e it bypassed chillers
+17:40 < Callum> i dont know, but im not sure how to show it all
+17:40 < Callum> im sure what iv got is somewhat decent
+17:41 < jtanx> I used visio and I ended up spending so much time trying to get the lines rihgt
+17:41 < jtanx> probably would have been faster to hand draw it
+17:41 < jtanx> still not finished too
+17:41 < Callum> haha im fiarly sure i read somewhere it was hand drawn :p
+17:41 < jtanx> meh I suck at drawing
+17:42 < Callum> maybe not. "This is to be drawn and annotated on single A4 page"
+17:42 < Callum> i dont think they'll be picky
+17:42 < jtanx> and there's lines everywhere
+17:42 < Callum> really? how do you have lines everywhere?
+17:42 < jtanx> ok so chiller
+17:42 < Callum> it's a fairly simple system. unless i'v done it wrong :s
+17:43 < jtanx> has warm chilled water (1), chilled coolant (2), hot coolant (3), chilled chilled water(4), control line (5), (maybe) sensor back to controller (6)
+17:43 < jtanx> that's ~5 lines in/out of one box?
+17:44 < Callum> hmm. havent included coolant or control/sensor
+17:44 < Callum> maybe i should :S
+17:44 < jtanx> and an operator
+17:44 < jtanx> to the controller
+17:45 < Callum> thing is it asked for a high level FBD though
+17:45 < Callum> which means not very detailed
+17:45 < Callum> or maybe it didnt?
+17:45 < jtanx> yeah, so do you need to show condensor/evaporator
+17:45 < jtanx> I just have a chiller box
+17:46 < jtanx> anyway... afk ~10 mins
+17:46 < Callum> the condensor/evaporater is part of the chiller isnt it?
+17:46 < Callum> ok
+18:10 < Callum> anyone finished reading chapter 4 of the notes?
+18:11 < jtanx> what's that
+18:11 < Callum> sensors
+18:12 < Callum> so dull :l
+18:12 < Callum> and pretty much no chance to remember enough of it. quiz tomorrow is going to be fun..
+18:12 < jtanx> oh
+18:13 < jtanx> shit
+18:13 < jtanx> have to study for that
+18:13 < Callum> rofl
+18:14 < jtanx> :/
+18:15 < Callum> gonna just have to wing most of them again like last time most likely.
+18:15 < jtanx> probably
+18:15 < jtanx> Well, the unit testing thing works http://mctx.us.to:8080/unit-tests/
+18:15 < jtanx> now what unit tests should there be
+18:18 < Callum> not sure.
+18:25 < Callum> brilliant! the notes show a false colour image built from a black and white image...while printed in black and white.
+18:34 < jtanx> :P
+19:50 < jtanx> um
+19:50 < jtanx> did we get around to doing the sparkplus thing
+19:54 < jtanx> we need to do it before the end of the week
+19:54 < Callum> umm.
+19:54 < Callum> actually justin already set up the group
+19:54 < Callum> so you need to hurry up and join before we have to recreate the group :P
+19:54 < jtanx> nah it expired
+19:54 < Callum> wait already?
+19:54 < Callum> zzz
+19:55 < jtanx> 5 hr deadline
+19:55 < Callum> and adrian said it was 24Hr, whats with this 5 hour shit
+19:55 < jtanx> so... we need to try again
+19:55 < jtanx> when everyone's available
+--- Day changed Thu Aug 29 2013
+09:16 < jtanx> firefox blocks ajax calls if you try to run the file locally :/
+09:45 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+14:25 < james__> Hey Jeremy. Is there a way to find my login hash key if i am already logged into the api?
+14:28 < jtanx> um
+14:28 < jtanx> right now you should store it
+14:29 < jtanx> just declare a global variable and set it to the hash
+14:30 < jtanx> or if you have made a class
+14:30 < jtanx> just make it an element
+14:31 < james__> I'm still logged in from ages ago and i can't logout so i can get a different key that works
+14:31 < jtanx> that
+14:31 < jtanx> ok
+14:31 < james__> Possibly a bug that needs fixing?
+14:31 < jtanx> so the way it works right now is there's a 3 minute timeout on the key
+14:31 < jtanx> no
+14:31 < jtanx> there's actually two layers
+14:32 < jtanx> the password that you enter first (mctxadmin) is what's called HTTP basic authentication
+14:32 < jtanx> this lets you gain access to /api/login
+14:32 < james__> Well i tried loging in again and its saying i am already logged in
+14:32 < jtanx> when you reach /api/login you get the access key
+14:32 < jtanx> there's a three minute timeout on the key
+14:32 < jtanx> if you wish to invalidate the key
+14:33 < jtanx> you call
+14:33 < jtanx> /api/login?end
+14:34 < jtanx> you can force getting a key by also calling /api/login?force
+14:34 < james__> right. well it worked this time
+14:34 < james__> Thats weird
+14:34 < jtanx> so the only thing that the key prevents is stopping accidental concurrent use
+14:34 < james__> Fair enough
+14:35 < jtanx> Calling /api/login?force will force a new key to be generated and the old one to be invalidated
+14:35 < james__> Okay
+14:35 < jtanx> btw as I was working on unit testing
+14:35 < jtanx> I did a function to retrieve the json data
+14:36 < jtanx> http://mctx.us.to:8080/unit-tests/unit-tests.js
+14:37 < james__> I will have a look. I have some buttons working and stuff. Working on putting them in a seperate script file for easier editing etc
+14:37 < james__> They don't seem to be playing nice at the moment
+14:37 < jtanx> ok
+14:38 < jtanx> how come it takes so much effort to get some buttons working
+14:39 < james__> Getting the css to mesh with the js
+14:40 < james__> I have buttons fine
+14:40 < james__> And they work
+14:40 < jtanx> maybe you should get the functionality to work first
+14:40 < jtanx> with the ajax queries
+14:40 < jtanx> before worrying about styling them
+14:40 < james__> I have the functionality pretty much working
+14:41 < jtanx> so the querying works?
+14:41 < james__> But i want the styling to work before we scale it up
+14:41 < james__> That way its less hassle to fix it later
+14:41 < jtanx> could you post it to git?
+14:41 < jtanx> it'd be cool to have a look
+14:45 < james__> The way i am thinking about having it set out is having a central index.html which just imports all the js. The js will contain all the functionlity seperated in to similar functions. Ie. all the buttons in one script
+14:46 < jtanx> right
+14:46 < james__> That should allow for ease of scaling and editing
+14:46 < james__> Also changing id's and stuff
+15:46 -!- james__ [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+21:09 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+23:18 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Fri Aug 30 2013
+17:06 < jtanx> say you want to perform a command
+17:06 < jtanx> eg move an actuator
+17:07 < jtanx> and suppose checks have to be made against other sensors to ensure that this command is good to go
+17:07 < jtanx> how are those checks going to be made?
+18:10 < sam_moore> The Actuator Handler will call some sanity check against the most recent sensor data
+18:11 < sam_moore> If they aren't, it will respond with some appropriate JSON or HTTP status code
+18:11 < sam_moore> eg: "Try again later when the pressure is in the right range", or "Don't do that you silly person"
+18:15 < jtanx> ._.
+18:21 < jtanx> I wonder if there's a way to pull from your git repository without creating the 'merge branch master from...' commits
+18:22 < sam_moore> I don't think so
+18:22 < jtanx> I tried playing with rebasing but it doesn't work out so well
+18:40 < jtanx> ok so I've committed some stuff to my repository that changes the handling of controls/actuators/login
+18:41 < jtanx> I'm not sure if it's the best way to do it
+18:41 < jtanx> though
+18:41 < jtanx> What I did was get rid of /api/login
+18:41 < jtanx> and instead have /api/control
+18:41 < jtanx> All of the control code (eg actuators but may be other controls? Start/stop the whole thing?) has been moved to controls.c
+18:42 < jtanx> You still need to supply username and password to access /api/control
+18:42 < jtanx> and what was previously called the 'authorization key' is now the control key (ie who has control)
+19:00 < sam_moore> Ok, I'll take a look at it later
+19:01 < sam_moore> Don't worry about the merge messages, it's not a big deal
+19:06 < jtanx> ok thanks
+20:27 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:03 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sat Aug 31 2013
+15:30 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+20:48 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+--- Day changed Sun Sep 01 2013
+14:17 < jtanx> it'd have been cool to have written then server in python
+14:19 < Callum> gah havent done much for this project this week. not sure what i should do either
+14:19 < jtanx> hmm
+14:19 < Callum> so far behind in one of my units too. haha joys of uni
+14:19 < jtanx> lol
+14:20 < jtanx> werent we meant to get the camera stuff working or something
+14:21 < Callum> well yea but thats more rosher getting stuff working on his end. still not really sure what's going on. need to find an efficient way to transfer data (which would be directly streaming but it seemed adrian wanted some sort of processing)
+14:21 < Callum> guess i could start working on edge detection
+14:21 < jtanx> james hasn't got much done afaik
+14:21 < Callum> nah dont think he ahs
+14:22 < jtanx> but man I was looking at the javascript stuff
+14:22 < jtanx> and it's really annoying
+14:22 < jtanx> everything in javascript is asynchronous
+14:22 < jtanx> so you have a callback for an AJAX query, and it gets executed some time in the future
+14:23 < jtanx> it's really hard to pass variables to the callback and then also retrieve them
+14:23 < Callum> hmm
+14:23 < jtanx> i'm probably not doing it in the right fashion or something
+14:28 < Callum> not sure. don't really understand this stuff myself. havent done much/any
+14:45 < jtanx> flask is so cool
+15:01 < jtanx> oh
+15:02 < jtanx> maybe we can use cookies to store authorization
+15:02 < jtanx> instead of in javascript
+15:02 < jtanx> hmm
+15:02 < jtanx> http://stackoverflow.com/questions/15722795/how-to-create-a-cookie-with-fastcgi-nginx-in-c
+15:57 < sam_moore> Maybe a cookie is better, but couldn't you have a global variable that the JavaScript code sets in the callback?
+15:57 -!- Irssi: #mctxuwa_softdev: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal]
+15:59 < sam_moore> Ok, I'll do the simulated "digital" sensor and actuator
+15:59 < sam_moore> We should make some kind of minimal gui in JavaScript
+16:00 < sam_moore> I'm not sure what James has done, but there's nothing under git
+16:02 < sam_moore> http://www.flotcharts.org/flot/examples/ajax/index.html is a good starting point for updating sensor graphs
+16:03 < sam_moore> jtanx: I wouldn't worry about the login/authentication too much for this week
+16:04 < jtanx> james said he got the buttons working but that's about it
+16:04 < jtanx> he's more concerned about issues with styling them than getting a fully fledged gui
+16:04 < sam_moore> I think actually having a gui is more important than having a pretty gui
+16:04 < sam_moore> At the moment anyway
+16:05 < jtanx> yeah
+16:05 < jtanx> it would be great to have *something*
+16:05 < jtanx> the problem with js
+16:05 < jtanx> is from what i've seen, the callback occurs in the jQuery file
+16:06 < jtanx> so you can't set global variables in say sensors.js
+16:06 < jtanx> and expect to be able to read/set them in the callback
+16:06 < sam_moore> Hmm, that's wierd
+16:06 < jtanx> what really shits me about javascript is variable handling
+16:06 < sam_moore> Hang on, let me have another look at the only project I ever used jQuery for... :P
+16:07 < jtanx> you can pass one/none/more than specified parameters
+16:07 < sam_moore> It was a chess game, so it should definietly be possible to modify variables in the callback function
+16:07 < jtanx> yeah there's probably a way, I just don't know it
+16:08 < jtanx> about the actuators
+16:08 < jtanx> I've already got something working in my repository
+16:08 < jtanx> but I don't really like how I've done it
+16:30 < sam_moore> I'm making a minimal gui (it will be able to plot something, and have a button); we can either ditch it or improve on it later
+16:31 < jtanx> sounds good
+16:35 < sam_moore> Callum: If you want to make a (really awful but possibly looking good enough at this stage for Adrian) "streaming" images thing
+16:35 < sam_moore> You can have your program continuously save to a file
+16:35 < sam_moore> And a html page that just has "<meta http-equiv="refresh" content="0">" in the header
+16:35 < sam_moore> With a link to the image
+16:36 < Callum> alright il look into it
+16:36 < sam_moore> It's absolutely aweful, but it will give the effect of a really laggy video
+16:36 < jtanx> nice :P
+16:36 < sam_moore> You can improve it (if you get time) by having 2 images instead of one, with a symbolic link to swap between them
+16:38 < sam_moore> I'll bring the raspberry pi with the webcam tomorrow and we'll put everything on it to show Adrian
+16:38 < jtanx> hehehe
+16:38 < jtanx> can you install ffserver on the raspi?
+16:39 < sam_moore> Probably
+16:40 < jtanx> actually
+16:41 < jtanx> does our code run on the raspi?
+16:50 < sam_moore> Yes, at the moment
+16:54 < Callum> how are we integrating my code into it?
+17:01 < sam_moore> Keep it as a seperate process for now
+17:01 < Callum> alright
+17:01 < sam_moore> I'll modify the "run.sh" script to start both of them
+17:01 < sam_moore> Sigh javascript
+17:01 < sam_moore> So useful and yet so horrible
+17:02 < sam_moore> Still, I think if we can get our heads around it it is actually a nice way to do this
+17:09 < jtanx> the camera thing or the api or both?
+17:24 < sam_moore> The API
+17:24 < Callum> ok so how do i link to the image? (
+17:24 < sam_moore> Just put a html file in the /server directory for now
+17:25 < sam_moore> With <img src="path_to_image"> in the body somewhere
+17:29 < Callum> where are we going to put the images?
+17:31 < sam_moore> /server/images (?)
+17:31 < sam_moore> Wherever it seems logical I guess
+17:33 < sam_moore> If either of you are available earlier on Monday, I'm free for pretty much the whole day
+17:33 < sam_moore> Do you want to meet earlier and actually do coding as a group?
+17:37 < sam_moore> Dammit why does javascript remove the [] brackets when printing string representations of arrays
+17:37 < sam_moore> How are you supposed to tell what dimensions the array has...
+17:37 < jtanx> if you want sample code of how I printed the array of sensor values
+17:37 < jtanx> see the unit tests
+17:37 < sam_moore> Ok, thanks
+17:37 < jtanx> for (var i = 0; i < data.data.length; i++) {
+17:37 < jtanx> result += data.data[i][0] + ":" + data.data[i][1] + ", ";
+17:37 < jtanx> }
+17:56 < Callum> ok well iv done trhat, i think. you should probably check it to make sure its right
+17:58 < Callum> sent pull request. and i'v got food so brb
+17:58 < sam_moore> Ok, thanks
+17:59 < sam_moore> jtanx: You're right, altering variables on a successful ajax call is a pain in the ass
+17:59 < jtanx> hehe
+17:59 < sam_moore> ... You can modify html attributes really easily though
+17:59 < jtanx> true
+17:59 < jtanx> that's what I was thinking
+17:59 < sam_moore> Must resist urge to store data in a comment
+17:59 < jtanx> have a hidden input field?
+18:01 < jtanx> I must say that the firebug debugger and inbuilt web console were both quite useful
+18:02 < sam_moore> Yes, I've got firebug running
+18:04 < jtanx> I was looking at flask and it was ridiculously easy to set up a similar API in python
+18:05 < sam_moore> Do you want to change to python then?
+18:06 < sam_moore> Don't we still have to do the javascript though?
+18:07 < sam_moore> The API we have at the moment isn't that terrible
+18:07 < jtanx> nah
+18:07 < jtanx> it's probably best to stick with what we have
+18:07 < jtanx> the javascript stuff would remain the same yeah
+18:09 < sam_moore> Ok
+18:26 < sam_moore> Right... you can update global variables on a successful AJAX request
+18:27 < sam_moore> If you put "var" in front of the variable in the global scope then the AJAX callback will just make a new local variable and modify that -_-
+18:27 < sam_moore> But if you Don't put the "var" there, it will work
+18:40 < jtanx> lol
+18:41 < jtanx> but using global variables in javascript can get.... messy
+18:41 < sam_moore> Mmm
+18:42 < sam_moore> But doing pretty much *anything* in javascript is messy
+18:42 < jtanx> yeah
+18:42 < jtanx> true that
+18:43 < sam_moore> I wonder...
+18:43 < sam_moore> Should we just have one html page for each sensor/actuator
+18:43 < sam_moore> And then the user can open multiple tabs?
+18:45 < sam_moore> That's probably not very nice though
+18:46 < sam_moore> I think we should return data about multiple sensors at a time
+18:51 < jtanx> you'd probably want it all on one page
+18:51 < sam_moore> Yeah
+18:51 < jtanx> how many sensors are we talking about again
+18:51 < sam_moore> 6 or 7 I think, + a camera
+18:51 < jtanx> oh yeah
+18:51 < sam_moore> Oh well, we can redesign it later
+18:51 < jtanx> I guess we can design for max 7
+18:52 < sam_moore> But it might be a good idea to query multiple sensors in one ajax request
+18:53 < jtanx> yep
+18:53 < jtanx> supply more than one id in a go?
+18:53 < jtanx> could have an array (max size 7) that holds all the sensors you want to get data for
+18:53 < jtanx> i guess
+18:55 < sam_moore> It's probably more flexible to just add a "getall" key to the sensor module
+18:57 < jtanx> oh yeah
+18:57 < jtanx> I'm free until 12 tomorrow
+18:57 < jtanx> do you want to work together before that?
+18:58 < sam_moore> Sure
+18:59 < sam_moore> Try G19 again, but if that doesn't work we can go to the physics lab, or the computer science labs
+19:01 < jtanx> yeah ok
+19:02 < jtanx> what time do you want to start?
+19:04 < sam_moore> I'll probably get in around 9 or 10, depending on how much sleep I get
+19:04 < sam_moore> Let's say 10:00
+19:05 < sam_moore> Got to go, I'll be back later
+19:05 < jtanx> ok
+21:35 < sam_moore> I'm just going to use the same Sensor stuff for digital sensors
+21:36 < sam_moore> Adding a second type of sensor seems needlessly complicated
+21:36 < sam_moore> 1 = on and 0 = off
+21:37 < sam_moore> Probably do the same for actuators (just have some sanity checks on the values you can set, both at the client and the server)
+21:38 < jtanx> usually I'd just say 0 is off and not 0 is on
+21:38 < sam_moore> Haha, fair enough
+21:39 < jtanx> I kinda hate over-checking stuff :P
+21:39 < sam_moore> The actual GetData function has to return something reasonably sane though
+21:39 < sam_moore> It's easy to just make it only return 0 or 1
+21:39 < jtanx> oh I was more talking about setting the value of the actuator
+21:39 < sam_moore> Right
+21:40 < sam_moore> We should probably check for 0 or 1 anyway
+21:40 < sam_moore> In case the user does something dumb
+21:40 < jtanx> well
+21:40 < sam_moore> Like think they are setting an analog sensor and put in like "200"
+21:40 < jtanx> it should be the js code that's setting it
+21:41 < jtanx> so if you write the code properly it shoul be ok
+21:41 < sam_moore> "should be OK"...
+21:41 < jtanx> you shouldn't access the api directly
+21:41 < sam_moore> Alright, we'll see, but it's like, 1/2 a line of code to check :P
+21:41 < sam_moore> Redundancy and all that
+21:41 < jtanx> but even if they entered 200
+21:41 < jtanx> well so what
+21:41 < sam_moore> Yeah, but people *can* access the API directly
+21:41 < jtanx> it'd just represet 1
+21:42 < jtanx> represent
+21:42 < jtanx> *
+21:42 < sam_moore> How does the server know the difference between someone typing the URL and an AJAX request to the URL?
+21:42 < jtanx> yeah
+21:42 < sam_moore> Someone could go view source, "How can I break this... ah, what happens if I pass stupid values directly to the API"
+21:42 < jtanx> well if you define that 0 is off and not zero is on
+21:43 < jtanx> then it meets specs :P
+21:43 < sam_moore> Ok, I suppose it doesn't really matter
+21:44 < sam_moore> I respectfully disagree with the idea of having too many checks :P
+21:44 < sam_moore> Unless we went "while (true) DoCheck();" or something like that
+21:44 < sam_moore> That would be dumb
+21:44 < jtanx> hahaha
+21:45 < jtanx> but sometimes it gets really messy to maintain when you have that many checks
+21:45 < jtanx> and then when you want to modify something it's a real pain
+21:45 < jtanx> and really easy to break
+21:45 < sam_moore> True, but a bounds check isn't that bad
+21:46 < jtanx> yrue
+21:46 < sam_moore> I mean, you have to convert the value that isn't zero to an "on" anyway, which requires a check
+21:46 < jtanx> not really
+21:46 < sam_moore> Depends on the actuator
+21:46 < jtanx> you check if !value
+21:47 < sam_moore> Alright
+21:58 < jtanx> do you think there should be a stop/start method?
+21:58 < jtanx> eg start the experiment
+21:58 < jtanx> stop the experiment
+22:28 < sam_moore> Yes, probably
+22:28 < sam_moore> The stuff I wrote for Thread Exit conditions may actually help there...
+22:29 < sam_moore> Remove the bit where the FCGI loop exits though
+22:29 < jtanx> yeah
+23:09 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]