**** BEGIN LOGGING AT Thu Jul 30 02:59:58 2015
Jul 30 13:00:34 <alexanderhiam> neem0: how goes it? Does the current plan sound good to you? Are you making progress with the Python framework?
Jul 30 14:05:00 <apaar_> alexanderhiam :managed to reduce pru latency from 352 cycles for 4 bytes to 232 cycles but for some reason the 4 bytes of th int get inverted :P
Jul 30 14:05:24 <Abhishek_> endianness?
Jul 30 14:06:01 <alexanderhiam> like the bits of each byte get inverted, or the order of the bytes?
Jul 30 14:06:23 <apaar_> order so it is probably just some issue with my write order working on it...
Jul 30 14:06:45 <Abhishek_> apaar_: Link to the relevant code?
Jul 30 14:06:59 <apaar_> Abhishek_ :i have not commited the code give me a sec
Jul 30 14:07:12 <Abhishek_> just gist it for the moment
Jul 30 14:07:22 <Abhishek_> apaar_: ^
Jul 30 14:10:12 <alexanderhiam> ds2: did you happen to get paid by packt?
Jul 30 14:10:47 <apaar_> Abhishek_ :did not see,i just commited it :P
Jul 30 14:19:39 <Abhishek_> alexanderhiam: I suppose that's a part of their contract with the author?
Jul 30 14:20:23 <alexanderhiam> the contract describes two advance payments... neither of which I've seen :(
Jul 30 14:22:05 <Abhishek_> did you reach out to them about it?
Jul 30 14:28:47 <alexanderhiam> I just sent my second email about it, my first being on July 7th with no response
Jul 30 16:01:37 <neemo> alexanderhiam nerdboy: 'ello
Jul 30 16:02:04 <neemo> alexanderhiam: And, goes quite well thanks for asking, works for me, and working on it
Jul 30 16:02:47 <neemo> I've been coding and I can say I'll tarnish my reputation of not pushing stuff until it's really really done
Jul 30 16:03:18 <neemo> which saddens me a bit, but I can ask you guys for help, which makes my job easier and probably makes everyone happier
Jul 30 16:04:16 * neemo is kinda squeamish and doesn't like pushing code which is note really there yet, sorry
Jul 30 16:05:11 <neemo> anyway, I've added support for reading the on-die temparature to the library (with no help from InvenSense's datasheets. thank you very much.)
Jul 30 16:05:48 * neemo isn't sure if that company really trying to be bad at developer outreach or they're just terrible at it 
Jul 30 16:06:11 <neemo> s/really/is really
Jul 30 16:06:53 <neemo> I've practically given up on them and started using other peoples' code as guidelines
Jul 30 16:06:56 <nerdboy> push/vote early and aften...
Jul 30 16:07:03 <nerdboy> *often even
Jul 30 16:07:20 <neemo> pushed
Jul 30 16:07:28 <neemo> it's here -> https://github.com/nvisnjic/PyBBIO/blob/master/bbio/libraries/MPU9250/MPU9250.py as it should be
Jul 30 16:07:36 <neemo> got the example code updated as well, so it's testable
Jul 30 16:08:18 <neemo> apart from the not so obvious but easy temparature sensor fix (which was practically taking random constants from someone elses code, it is kinda precise, or so I tested)
Jul 30 16:08:43 <neemo> I've added the code for controlling the range for the gyro and accelerometer
Jul 30 16:09:01 <neemo> will be adding the code for the magnetometer later, but it's different since I have to play with internal I2C
Jul 30 16:09:36 <neemo> I've wanted to try and make the library as accesible as possible to somebody encountering the MPU9250 for the first time
Jul 30 16:09:46 <alexanderhiam> neemo: I'd recommend not use uppercase for RANGE_CURR_GYRO, etc.
Jul 30 16:10:11 <alexanderhiam> the convention in Python is that the uppercase variables are constants and shouldn't be changed
Jul 30 16:10:19 <neemo> and I've added the possible range parameters in a kinda enum, so it's more, erm API like for lack of better word
Jul 30 16:10:28 <nerdboy> your package should depend on BBIO
Jul 30 16:10:33 <neemo> alexanderhiam: roger that
Jul 30 16:10:50 <neemo> nerdboy: doesn't it depend already?
Jul 30 16:11:02 <neemo> I mean the input part at least does
Jul 30 16:11:29 <neemo> alexanderhiam: is the enum type thing OK, those that make sense from a usability standpoint, or can I make that easier in some way
Jul 30 16:11:32 <neemo> ?
Jul 30 16:11:36 <neemo> wanted to have something like
Jul 30 16:11:48 <nerdboy> i meant with its own setup.py etc
Jul 30 16:11:54 <alexanderhiam> um... why not use the standard Python types and conventions?
Jul 30 16:12:05 * nerdboy not clear about forking the library
Jul 30 16:12:05 <neemo> mpu.setRangeGyro( RANGE_GYRO.2000DPS)
Jul 30 16:12:36 <neemo> alexanderhiam: well, I could, but wasn;t actually sure which type to use to achieve this
Jul 30 16:12:44 <alexanderhiam> seems awkward to me
Jul 30 16:13:04 <neemo> essentially it would be like using enums in C to hide numbers behind more easily understandable names for setup variables
Jul 30 16:13:08 <alexanderhiam> I'd probably just use class attributes
Jul 30 16:13:25 <alexanderhiam> e.g. MPU9250.RANGE_GYRO_2000DPS
Jul 30 16:13:25 <neemo> fair enough, that's why I pushed it to see if you guys got any better ideas
Jul 30 16:13:43 <neemo> since in C i would go for eunms, but Python I have no idea what to use in that place
Jul 30 16:13:57 <alexanderhiam> awesome, that's what we're here for
Jul 30 16:14:00 <neemo> well, ok, that works! :D
Jul 30 16:14:18 <neemo> and removes the awkwardness of that whole self.enum(self self self
Jul 30 16:14:19 <neemo> construct
Jul 30 16:14:39 <neemo> So... make a  8 static variables for the possible ranges and use that?
Jul 30 16:15:07 <neemo> any "smarter" options, or should I stick with that , since that's the simplest approach
Jul 30 16:15:11 <neemo> ?
Jul 30 16:15:40 <alexanderhiam> that's fine, it's consistent
Jul 30 16:15:51 <neemo> roger that, will make the changes
Jul 30 16:16:06 <neemo> I'll finish the setRange() methods in a bit
Jul 30 16:16:18 <neemo> then add the self test and offset stuff, probably tonight even
Jul 30 16:16:36 <neemo> and the library should be mostly done, at least what I've had in mind for it
Jul 30 16:16:56 <neemo> then I can write the basic framework for accessing that data
Jul 30 16:17:14 <alexanderhiam> "The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." - Knuth
Jul 30 16:17:19 <neemo> and eventually tie it up with a solver (looks at nerdboy with expectation )
Jul 30 16:17:53 <alexanderhiam> neemo, nerdboy: I'm sending out an email now to make it clear what needs to happen in the very short time remaining
Jul 30 16:18:10 <neemo> roger
Jul 30 16:18:40 <neemo> also, roget on the optimization part (should read Knuth after GSoC)
Jul 30 16:18:57 * neemo set to -O0
Jul 30 16:19:16 <alexanderhiam> email sent
Jul 30 16:19:29 * alexanderhiam will be afk for a few hours probably
Jul 30 16:19:38 <neemo> ok
Jul 30 16:19:46 <neemo> thanks for the feedback alexanderhiam
Jul 30 16:19:56 <neemo> I'll keep you guys posted on the progress of the code
Jul 30 16:20:11 <neemo> and will keep pushing code up as it gets done
Jul 30 16:20:17 <alexanderhiam> great
Jul 30 16:20:34 * neemo goes to read mail
Jul 30 16:20:42 <alexanderhiam> also, feel free to send a pull request for the MPU9250 driver
Jul 30 16:21:39 <nerdboy> http://www.gentoogeek.org/files/knuth_homework.jpg  <=  my first meme...
Jul 30 16:25:11 * neemo is done reading
Jul 30 16:26:12 <neemo> alexanderhiam, nerdboy : All I want to say for now is that I completely agree with everything said nad I most definitely plan to do everything I can to finish of all the items on that list
Jul 30 16:27:19 <neemo> I currently think the Python part is doable within the timeframe, especially if a solution for the solver can be found
Jul 30 16:27:45 <neemo> But i'll be focusing most of my efforts on the framework, since for now I've been focusing too much on the solver and algorithm (or so I think)
Jul 30 16:28:12 <neemo> I'll write up a proper email response a bit later
Jul 30 16:28:39 <nerdboy> http://www.gentoogeek.org/files/darth.jpg  <=  this one i made at my last job...
Jul 30 16:29:11 <neemo> quick question though, nerdboy alexanderhiam is the current level of documentation (eg. python library) satisfactory?
Jul 30 16:29:37 <neemo> ei is the library documented correctly/in enough detail
Jul 30 16:29:55 <neemo>  doxygen hook shouldn't be a problem later, but I don't have it very high on my priority list at this moment
Jul 30 16:31:30 <neemo> afk for a sec, making foodstuffs/dinner
Jul 30 16:32:00 <nerdboy> looks "okay" for now i guess, would be nice to see some parameter descriptions at some point...
Jul 30 16:32:52 <neemo> nerdboy: I'll added for the ones I kinda made up. eg range_curr_gyro, though that's kinda self explanatory
Jul 30 16:33:15 <neemo> but I'll leave documenting REGs from the datasheet for later/whenIhavetime
Jul 30 16:33:46 <neemo> I'll be documenting obscure but crucial stuff which was leftout/hidden by InvenSense as I go though
Jul 30 16:34:34 <nerdboy> anything that took work to figure out at the top of the list...
Jul 30 16:34:42 <neemo> e.g. the constants used to compute on-die temperature (they don't state their values in no available pdf, pissed me off)
Jul 30 16:34:53 <neemo> yeah, that's what I was thinking
Jul 30 16:35:03 <neemo> the I2C stuff for the magnetometer, for example
Jul 30 16:35:33 <neemo> ok, anyway, food, be right back
Jul 30 16:35:49 <neemo> have to get something before I collaps, but I'll be around later to code and/or chat :)
Jul 30 17:30:06 <azizulhakim> _av500_: ping
Jul 30 18:45:12 <vvu> moto-timo: ping
Jul 30 19:11:26 <neemo> nerdboy: alexanderhiam, minor implementation question for the library
Jul 30 19:11:44 <neemo> I have to know the current range for gyro and accel to know the scaling multiplier
Jul 30 19:12:29 <neemo> should I just read the register that holds the settings value, or keep the scale in a separate attribute and set/read/update it accordingly and use that to decide on my scaling multiplier on data reads
Jul 30 19:12:33 <neemo> ?
Jul 30 19:24:25 <ds2> guessing you should keep it seperate
Jul 30 19:24:35 <ds2> the scaling depends on chip config and the chip itself
Jul 30 19:29:45 <neemo> ds2: through, but I wasn't reffering to the values I can set
Jul 30 19:30:03 <neemo> I hardcode those for the specific chip, so to be able to set it properly up
Jul 30 19:30:19 <neemo> the question was more when I read values from the MPU9250
Jul 30 19:30:24 <neemo> let's say the gyro values
Jul 30 19:30:43 <ds2> the raw 16bit counts, right?
Jul 30 19:30:57 <neemo> I have to know what range was used in that mesurement, one way to know the range is to keep an internal atribute to the MPU object in the library
Jul 30 19:31:03 <neemo> the other is to read the register with the values
Jul 30 19:31:18 <ds2> I'd not read the register
Jul 30 19:31:22 <neemo> right after that read the register with the scaling/measurement settings and use that
Jul 30 19:31:29 <ds2> takes too long...weren't you doing this at a high sample rate?
Jul 30 19:32:14 <ds2> on i2c, the bus is pretty crowded but you are on SPI. nevertheless,it translates to power consumption
Jul 30 19:32:20 <neemo> maximum is 8Khz if I remember correctly
Jul 30 19:32:29 <neemo> ds2: true that
Jul 30 19:32:34 <ds2> yes so -
Jul 30 19:32:37 <neemo> ok, attribute to object it is
Jul 30 19:32:44 <neemo> thanks ds2
Jul 30 19:32:49 <ds2> X/Y/Z/T = 8 bytes for gyro
Jul 30 19:33:00 <ds2> 6 bytes for accel
Jul 30 19:33:04 <ds2> 6 bytes for mag
Jul 30 19:33:07 <neemo> 8 bytes for accel
Jul 30 19:33:10 <neemo> 6 for mag
Jul 30 19:33:16 <neemo> 8 / 8 / 6
Jul 30 19:33:21 <ds2> 8 for accel?
Jul 30 19:33:24 <ds2> X/Y/Z and?
Jul 30 19:33:26 <neemo> if I read the scaling values from the chip
Jul 30 19:33:28 <neemo> yup
Jul 30 19:33:32 <ds2> ah
Jul 30 19:33:34 <ds2> not including that
Jul 30 19:33:39 <neemo> X Y Z and scaling ei. measurement range
Jul 30 19:33:45 <neemo> so without those
Jul 30 19:33:53 <neemo> its 6 / 6 / 6 bytes
Jul 30 19:33:54 <neemo> of data
Jul 30 19:34:18 <neemo> high and low for each of X, Y & Z
Jul 30 19:34:27 <ds2> 20 bytes or 160 bits 1280000 (1.2MHz) of SPI data just for data itself
Jul 30 19:34:45 <ds2> you are not pulling the temperature?
Jul 30 19:34:51 <neemo> ah yes
Jul 30 19:34:59 <neemo> temp as well, so 2 bytes more
Jul 30 19:35:09 <neemo> but I set it up so I can selectively pull any of those
Jul 30 19:35:11 <ds2> that 1.2MHz  doesn't include register number overhead
Jul 30 19:35:18 <neemo> ei getMag()
Jul 30 19:35:20 <neemo> getGyro
Jul 30 19:35:22 <neemo> getTemp
Jul 30 19:35:24 <neemo> ...
Jul 30 19:35:39 <ds2> yes but there is an overhead to doing it
Jul 30 19:35:49 <ds2> I am assuming a burst read
Jul 30 19:36:13 <ds2> do you recall what is the max speed of the SPI bus for this chip?
Jul 30 19:36:16 <neemo> sure, the overhead is in the functions themselves, having a single one will be faster (haven't tested yet)
Jul 30 19:36:27 <ds2> no no no
Jul 30 19:36:34 <neemo> ?
Jul 30 19:37:11 <neemo> max speed is 1Mhz for SPI
Jul 30 19:37:18 <ds2> to read a register, you need to clock out the register address
Jul 30 19:37:18 <ds2> if you read it one at a time, you need to keep clocking out register address. the alternative is to clock it out once and use the internal auto increment aka burst mode to read successive addresses
Jul 30 19:37:34 <ds2> the register address clocking is the overhead I am talking about
Jul 30 19:37:41 <neemo> they mention some 20Mhz data transfer via SPI, but It's not really documented well
Jul 30 19:38:03 <ds2> 1MHz won't sustain A/M/G @ 8KHz
Jul 30 19:38:08 <ds2> esp. if you do not use the fifos
Jul 30 19:38:20 <neemo> A & M is 8Khz
Jul 30 19:38:22 <neemo> sorry
Jul 30 19:38:24 <neemo> A & G
Jul 30 19:38:29 <ds2> recommend you check for losses
Jul 30 19:38:34 <neemo> M is 8 Hz
Jul 30 19:38:34 <ds2> how fast is the M?
Jul 30 19:38:34 <neemo> max
Jul 30 19:38:44 <ds2> oh 8Hz blah
Jul 30 19:38:48 <neemo> yeah
Jul 30 19:38:59 <neemo> crappy, but its essentially a sandwiched die
Jul 30 19:39:11 <neemo> the AK mag and the invensense gyro & accel
Jul 30 19:39:17 <ds2> 8 byte + 6 byte so 14 bytes @ 8KHz or 112bits @ 8KHz
Jul 30 19:40:00 <neemo> plus the mag must be accesed via internal I2C at max 400Khz, and than pass that through SPI to the BBB
Jul 30 19:40:05 <ds2> that's about 0.96MHz min speed
Jul 30 19:40:16 <neemo> but since it's at only 8 Hz refresh, the I2C shouldn't play a role there
Jul 30 19:40:35 <ds2> I seem to recall it can do better then 8Hz
Jul 30 19:40:49 <ds2> 1MHz SPI bus is very tight if that spec is correct
Jul 30 19:40:51 <neemo> and I'm currently accessing all the data via SPI readReg
Jul 30 19:41:17 <ds2> regardless, check for drops
Jul 30 19:41:37 <neemo> but I'll set up a fifo later for faster reads, tried before, but the documentation is really shitty, will copy code from other good people
Jul 30 19:41:45 <neemo> the mag can do only 8 Hz
Jul 30 19:41:57 <ds2> look at the drivers
Jul 30 19:42:03 <neemo> the other mag, the DNI one can do better, have to write a library for it though
Jul 30 19:42:27 <neemo> yeah, that's what I'm doing, oggling through all the drivers, they differ by quite a bit, but I get the info I need
Jul 30 19:42:29 <ds2> are you using auto sample mode on the AK chip?
Jul 30 19:42:50 <neemo> meaning, its in continous sampling mode?
Jul 30 19:42:53 <neemo> if yes, then yes
Jul 30 19:43:22 <neemo> 16 bit continous mode 1 from the data sheet, which should work for what I need it to work, just pull some mag data at 8 Hz
Jul 30 19:44:11 <neemo> ds2: need the link?
Jul 30 19:44:20 <neemo> it doesn't say much though
Jul 30 19:45:16 <ds2> ah that is your problem
Jul 30 19:45:23 <ds2> it can run faster if you manually sample it
Jul 30 19:45:54 <ds2> I usually run the mags faster
Jul 30 19:50:04 <neemo> ds2: so you recommend I build a routine that can use single read mode for the AK and read at a faster rate than 8 Hz?
Jul 30 19:50:31 <neemo> I got the impression is that 8 Hz is the maximum by specification, didn't think you can force the magnetometer to sample faster :?
Jul 30 19:51:33 <ds2> not in the scope of GSoC
Jul 30 19:51:36 <ds2> no time to do that
Jul 30 19:52:11 <ds2> Check your datasheet, I don't think they spec'ed an upper number
Jul 30 19:56:32 <neemo> ds2: curiously they didn't, I thought I saw 8 Hz as max
Jul 30 19:56:58 <neemo> but it just says that it uses 280μA at 8Hz repetition rate
Jul 30 19:57:14 <neemo> going to have to look into the AK mag datasheet to get the real info
Jul 30 19:57:53 <neemo> InvenSense didn't really impress with the documentation, neither the access nor the content
Jul 30 19:58:13 <neemo> But I'll look into it after GSoC, could be possible, maybe
Jul 30 19:58:56 <neemo> anyway, dedicated var for the current ranges, off to do that
Jul 30 20:04:53 <nerdboy> put a note in the comments/doc file
Jul 30 20:06:09 <nerdboy> okay, what's the "short" version of strtol?
Jul 30 20:09:14 <neemo> nerdboy: I have a conundrum
Jul 30 20:09:57 <neemo> so setting the ranges with mpu.setRangeGyro(mpu.RANGE_GYRO_2000DPS) is super nice from a usability point of view
Jul 30 20:10:49 <neemo> but I have to internally map that RANGE_GYRO_2000DPS to 11 when I edit/manipulate the range in the registers, while I need the number 2000 to be able to multiply with it when I need scaling
Jul 30 20:11:07 <neemo> best way to do that in python, or lets say most official way
Jul 30 20:11:10 <neemo> ideas?
Jul 30 20:12:14 <neemo> i can have two more converter functions that just catch the 0,1,2,3s and convert to the number I need
Jul 30 20:12:25 <neemo> but don't know if there's a more elegant way to do it
Jul 30 20:12:41 <neemo> s/to/them/
Jul 30 20:13:29 <nerdboy> you need to convert them on-the-fly?
Jul 30 20:13:30 <moto-timo> vvu: pong
Jul 30 20:14:57 <neemo> well, no
Jul 30 20:15:05 <neemo> I need to know the scaling value
Jul 30 20:15:07 <ds2> :)
Jul 30 20:15:36 <nerdboy> did you just answer your own question?
Jul 30 20:15:48 <neemo> pretty much
Jul 30 20:15:58 <neemo> still don't know what's the most elegant way
Jul 30 20:16:06 <neemo> the user wants to see 2000DPS
Jul 30 20:16:11 <nerdboy> if in doubt, try it and see...
Jul 30 20:16:22 <neemo> data sampling needs 2000 for the scaling
Jul 30 20:16:32 <neemo> I want a clean number 3 to put in the register
Jul 30 20:16:51 <nerdboy> make it tuple then?
Jul 30 20:16:54 <neemo> I need a three way dictionary is what I'm saying I guess
Jul 30 20:17:04 <neemo> hmmm
Jul 30 20:20:12 <neemo> nevermind... I'm stupid this early in the morning
Jul 30 20:20:33 <neemo> I'll use a tuple and the range will be the index
Jul 30 20:20:42 * neemo bumps himself on the table
Jul 30 20:26:55 * alexanderhiam returns to keyboard
Jul 30 20:27:24 <alexanderhiam> neemo: what ds2 said, definitely don't read the scaling values for every sample
Jul 30 20:27:35 <nerdboy> too late, ds2 got your cookie...
Jul 30 20:28:14 <alexanderhiam> it's nice to set defined default values when you first connect to the device
Jul 30 20:28:39 <alexanderhiam> that way you start out knowing your in sync, and your API docs can tell the user exactly what all the settings will be when they instantiate
Jul 30 20:29:20 * nerdboy instantiates a bagel...
Jul 30 20:34:29 * neemo init(cookie_jar) ?
Jul 30 20:34:40 <neemo> alexanderhiam: ds2 yeah thanks for the cue
Jul 30 20:34:53 <moto-timo> yummy = new(cream_cheese)
Jul 30 20:35:00 <neemo> the defaults were set safely in any case, but no need to waste time reading the regs
Jul 30 20:35:49 <alexanderhiam> once you've connected to the sensor and set a default config it's safe to assume you're the only one changing anything, i.e. you can trust your local attributes to be correct
Jul 30 20:42:43 <neemo> alexanderhiam: yup, makes sense
Jul 30 20:42:51 <neemo> I reset everything there is to reset on the first init
Jul 30 20:43:24 <nerdboy> anybody ever wonder why xorg-server has "issues"?
Jul 30 20:43:37 <nerdboy> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648  <=  good example
Jul 30 20:43:49 <nerdboy> maybe the canonical example...
Jul 30 20:43:50 <alexanderhiam> there's probably also a reset register that will ensure everything is set to the default settings in the datasheet
Jul 30 20:44:12 <vvu> moto-timo: sorry for the late answer, any news on flashing integration ?
Jul 30 20:45:36 <moto-timo> vvu: no news from arianepaola this week at all, except her report
Jul 30 20:45:58 <moto-timo> vvu: no commits since July 7th
Jul 30 20:46:48 <moto-timo> vvu: after GSoC is over, we might have to forge forward ourselves... but I have limited time right now
Jul 30 20:51:32 <neemo> curious
Jul 30 20:51:56 <neemo> can I set an object attribute from within a method, without declaring it first
Jul 30 20:52:25 <neemo> ei first time I write       self.CurrentRangeGyro = rangeVal
Jul 30 20:52:38 <neemo> is in an if statement in my setRangeGyro method
Jul 30 20:52:55 <alexanderhiam> yes, that's how python works
Jul 30 20:53:03 <alexanderhiam> there is no variable declaration
Jul 30 20:53:32 <alexanderhiam> because that's in a method run on an instance of a class it's creating an instance variable
Jul 30 20:53:52 <alexanderhiam> where as attributes set at the same level as the methods are defined are class variables
Jul 30 20:54:06 <neemo> yeah
Jul 30 20:55:08 <neemo> but that's why I'm confused when PyBBIO gives me AttributeError: 'MPU9250' object has no attribute 'currentRangeAccel'
Jul 30 20:55:39 <alexanderhiam> that'll happen if you try to access an attribute that hasn't been created yet
Jul 30 20:56:18 <neemo> hmmm
Jul 30 20:56:25 <neemo> sec
Jul 30 21:01:22 <neemo> well, Its officially to early
Jul 30 21:01:34 <neemo> notice the C and c in currentRangeAccel
Jul 30 21:01:37 <neemo> (sigh)
Jul 30 21:03:20 <alexanderhiam> that'll do it
Jul 30 21:03:28 <nerdboy> camelCase isn't really pythonic...
Jul 30 21:03:49 * alexanderhiam loves camelCase in Python
Jul 30 21:03:58 <nerdboy> unless someone slipped guido something in his drink
Jul 30 21:04:09 <alexanderhiam> boo to PEP8!!
Jul 30 21:04:21 <neemo> lol
Jul 30 21:04:47 <neemo> should I do half-half then, since you guys can't agree on the case
Jul 30 21:05:01 <neemo> :D
Jul 30 21:05:02 <alexanderhiam> oh lord no!
Jul 30 21:05:06 <neemo> hahaha
Jul 30 21:05:12 * neemo was waiting for that
Jul 30 21:05:12 <nerdboy> why i oughta...
Jul 30 21:05:19 <nerdboy> wise guy
Jul 30 21:05:21 <neemo> there goes the second
Jul 30 21:05:21 <neemo> xD
Jul 30 21:05:50 <alexanderhiam> if you're not sure about style stuff you can just stick to PEP8 though
Jul 30 21:06:16 <neemo> I'll try to be consistent
Jul 30 21:06:20 <alexanderhiam> standards are good, I just happen to personally hate that one
Jul 30 21:06:44 <neemo> even if I'm consistently bad at it, I'll be sure to come back and fix it later in the "make it nice" phase
Jul 30 21:06:56 <nerdboy> if that's your biggest beef then something is wrong...
Jul 30 21:07:30 * nerdboy has beefs with upstream that won't fix errors
Jul 30 21:07:46 <neemo> I'm ok with both really, tend to use the one that was used in the lib I'm adding to though
Jul 30 21:07:50 <neemo> also
Jul 30 21:07:53 <neemo> moar code!
Jul 30 21:07:56 <neemo> here -> https://github.com/nvisnjic/PyBBIO/blob/master/bbio/libraries/MPU9250/MPU9250.py
Jul 30 21:08:16 <neemo> set/get for Ranges works like a charm, got some sanity checks in as well
Jul 30 21:08:26 <neemo> will add some error code later
Jul 30 21:08:35 <neemo> what's error in python? error() :?
Jul 30 21:08:53 <alexanderhiam> Exception is the base class
Jul 30 21:09:00 * nerdboy testing patches for said upstream developer's stupid errors...
Jul 30 21:09:01 <neemo> will read on it
Jul 30 21:09:09 <neemo> but yeah
Jul 30 21:09:13 <neemo> range is done
Jul 30 21:09:21 <neemo> got selftests left, which shouldn't take too much
Jul 30 21:09:23 <alexanderhiam> the assert keyword is OK for simple things like type checks
Jul 30 21:09:25 <moto-timo> https://docs.python.org/2/tutorial/errors.html
Jul 30 21:09:29 <neemo> then framwork stuff
Jul 30 21:09:44 <nerdboy> looks like Xephyr is too broken for me to give a squat right now
Jul 30 21:09:51 <neemo> thank you moto-timo
Jul 30 21:09:56 * neemo likes links a lot
Jul 30 21:10:12 * alexanderhiam appreciates neemo's sticking to the same style as PyBBIO for that driver :)
Jul 30 21:10:30 <neemo> alexanderhiam: I used assert for the few check where my ints should REALLY MATCH
Jul 30 21:10:31 <moto-timo> define your own exception or error class and raise
Jul 30 21:10:50 <neemo> ag whoami's, since those would brake all functionality in the lib
Jul 30 21:10:56 <alexanderhiam> yeah, custom Excpetions with descriptive names are ideal
Jul 30 21:11:06 <neemo> something like a failed range change shouldn't break everything, or so I think
Jul 30 21:11:08 * nerdboy likes to see propagation of custom exception messages
Jul 30 21:11:53 <neemo> Exceptional Exceptions will do then
Jul 30 21:11:53 <alexanderhiam> there's often a sensible standard Exception you can through, like TypeError
Jul 30 21:11:57 <alexanderhiam> https://docs.python.org/2/library/exceptions.html#exceptions.TypeError
Jul 30 21:12:26 <neemo> alright
Jul 30 21:12:28 <neemo> will read
Jul 30 21:12:49 <neemo> but tomorrow! since my eyes are a bit displeased with me ATM
Jul 30 21:13:01 <neemo> well, erm, today actually
Jul 30 21:13:02 <nerdboy> add your own helpful/sarcastic hints
Jul 30 21:13:22 <neemo> since the sun is up, that's my cue to go and lay down with my hands crossed
Jul 30 21:13:45 <alexanderhiam> sleep can be very helpful at times
Jul 30 21:13:51 <neemo> preferably in a coffin like box with extra cushions
Jul 30 21:14:16 <neemo> yeah, counting on getting some
Jul 30 21:14:48 <neemo> well, that it for tonight, I'll be back with more in erm Xe[8,10] hours
Jul 30 21:15:21 <alexanderhiam> okey dokey
Jul 30 21:15:24 <neemo> We should be able to talk framework soon though
Jul 30 21:15:37 <neemo> so keep the solver ready for soon after that :D
Jul 30 21:15:49 <neemo> I'm off
Jul 30 21:16:02 <neemo> C y'all later
Jul 30 21:29:52 <vvu> moto-timo: mhmh same, looked over the github repo and no commits since long ago
Jul 30 21:34:36 <moto-timo> vvu: nwjs branch
Jul 30 21:36:12 <moto-timo> https://github.com/arianepaola/beaglebone-getting-started/tree/nwjs
Jul 30 21:36:35 <moto-timo> or look at mine for the travis-ci and appveyor attempts
Jul 30 21:36:56 <moto-timo> https://github.com/moto-timo/beaglebone-getting-started/tree/nwjs
Jul 30 21:37:15 <moto-timo> https://github.com/moto-timo/beaglebone-getting-started/tree/nwjs_osx
Jul 30 21:39:47 <nerdboy> that might be the stupidest upstream developer question too...
Jul 30 21:40:28 <nerdboy> xorg dev to gcc dev "How would gcc know that when you are compiling a completely unrelated source file??
Jul 30 21:41:07 <nerdboy> ^^ in reference to the same variable declared two different ways in two different source files...
Jul 30 21:41:24 <rcn-ee> well... you have to be insane to work on x11. ;)
Jul 30 21:41:34 <nerdboy> apparently
Jul 30 21:43:39 <nerdboy> "how would gcc know when i put the error so far apart?"
Jul 30 21:43:43 <moto-timo> rcn-ee: +1
Jul 30 21:44:07 <nerdboy> "you should fix gcc..."
Jul 30 21:44:13 <moto-timo> lol
Jul 30 21:44:26 <moto-timo> yeah, that's the problem
Jul 30 21:44:33 <nerdboy> dude, i wish i was kidding...
Jul 30 21:44:36 <moto-timo> can we ship him a mirror
Jul 30 21:44:50 <moto-timo> look at this, it pinpoints your problem
Jul 30 21:45:18 <nerdboy> with a big X written with a sharpie?
Jul 30 21:45:28 <moto-timo> in red
Jul 30 21:45:52 <moto-timo> maybe the dev is only 14 and just starting?
Jul 30 21:46:02 * moto-timo hopes so
Jul 30 21:50:48 <vvu> moto-timo: looked at the branch but last commit is from 23 days ago
Jul 30 22:06:57 <moto-timo> vvu: and that is why I am sad
Jul 30 22:07:01 <moto-timo> :(
Jul 30 22:09:58 <nerdboy> gsoc students take note ^^
**** ENDING LOGGING AT Fri Jul 31 02:59:58 2015