**** BEGIN LOGGING AT Wed Jun 24 02:59:58 2015
Jun 24 04:47:21 <neemo> hi all
Jun 24 04:48:56 <av500> hi
Jun 24 04:50:29 <neemo> av500: how's the audio thing going?
Jun 24 05:29:23 <av500> good
Jun 24 05:36:03 <vvu> hello all!
Jun 24 05:36:33 <neem0> vvu: hello
Jun 24 05:36:34 <av500> early for a meeting :)
Jun 24 05:36:51 <neem0> it's a preemptive meeting
Jun 24 05:36:52 <neem0> :)
Jun 24 05:37:27 <av500> neem0: report?
Jun 24 05:37:34 <av500> asking preemptively
Jun 24 05:39:27 <neem0> writing it up
Jun 24 05:39:30 <neem0> and elaborating a bit
Jun 24 05:39:36 <neem0> preemptively
Jun 24 05:39:48 <neem0> I'll push it to the web within the hour
Jun 24 05:40:16 * vvu is on the train 
Jun 24 05:40:42 <vvu> this one in .ro does not have wi-fi :(
Jun 24 05:41:22 <neem0> non fancy south european trains
Jun 24 05:41:48 <neem0> I feel your pain
Jun 24 05:47:54 <vvu> yeah...tomorrow i need to fly to SFO and no wi-fi also on the plane. at least extra leg room
Jun 24 05:50:04 <Abhishek_> gm
Jun 24 06:37:24 <neem0> av500: Abhishek_ : first look at the corr. algorithm ->  http://nvisnjic.com/2015/06/24/2d-correction-in-action.html
Jun 24 06:38:05 <neem0> nerdboy: here?
Jun 24 06:41:37 <neem0> oh, its 6 o'clock in the US, right.
Jun 24 06:45:39 <av500> its 23:45 in SFO
Jun 24 06:51:19 <neem0> hmmm, yeah you're right
Jun 24 06:51:37 <neem0> why does the log say 6 am
Jun 24 06:51:41 <neem0> is it Europe based?
Jun 24 06:52:35 <av500> 8:52 here
Jun 24 06:52:53 <av500> 6:52 might be GMT
Jun 24 06:53:00 <av500> yup
Jun 24 06:53:05 <av500> ZULU time
Jun 24 06:54:04 <Abhishek_> yup, logs are GMT
Jun 24 06:54:38 <Abhishek_> neem0: When do you plan to test out the algorithm on hardware?
Jun 24 06:54:43 <neem0> oh cool
Jun 24 06:54:55 <neem0> I hope as soon as possible
Jun 24 06:55:08 <neem0> I'll finish adding the 3rd axis today or tomorrow
Jun 24 06:55:37 <neem0> and I can start porting to C++ or C  next week or sooner
Jun 24 06:55:48 <Abhishek_> so this was in Octave?
Jun 24 06:56:12 <neem0> I'd like to add the time-varying correction to Octave first as well, this week should do it for all the Octave stuff I think
Jun 24 06:56:18 <neem0> yeah, more specifically MATLAB
Jun 24 06:56:43 <neem0> Octave refused to install the symbolic toolbox no matter what I did to it
Jun 24 06:56:57 <neem0> I'll cut out the MATLAB parts and think I can push it to Octave
Jun 24 06:57:41 <neem0> I can start testing from there even if it stays in Octave, don't have to really put it into native before optimizing
Jun 24 06:59:57 <neem0> Abhishek_: recommendations?
Jun 24 07:15:11 <neem0> av500: and the update http://nvisnjic.com/2015/06/24/gsoc-update-week4.html
Jun 24 07:15:25 <neem0> 35 minutes to slow
Jun 24 12:18:27 <Abhishek_> 3:30 to meeting
Jun 24 12:20:56 <shubhangi> Abhishek_: can you give me a start as to how other modules can plug into this framework.
Jun 24 12:22:04 <shubhangi> Abhishek_: i was thinking it can be the way a platform specific rproc framework plugs into the remopteproc core driver
Jun 24 12:23:03 <shubhangi> or lets say a uio platform driver into the core uio framework.
Jun 24 12:23:27 <Abhishek_> one of the important abilities here, you'd need ability to "trap" interrupts and route them to other modules
Jun 24 12:25:42 <shubhangi> okay, should the other module handle the interrupt or would it be just a notification that is sent.
Jun 24 12:27:12 <Abhishek_> you could handle the interrupt within the module, and send a callback
Jun 24 12:30:29 <shubhangi> the framework receives an interrupt, clears the event and passes it to the user module which handles it the way he wants. right ?
Jun 24 12:31:37 <Abhishek_> something like that, yes
Jun 24 13:03:13 <shubhangi> Abhishek_: were you able to run my code on your BBB ?
Jun 24 13:04:28 <Abhishek_> I was able to compile the driver in the 3.14 tree as of now, but yet to test it
Jun 24 13:05:17 <shubhangi> okay. give it a try when you get time
Jun 24 13:59:24 <Abhishek_> T-2
Jun 24 14:28:25 <alexanderhiam> shubhangi: it would be nice if the firmware loading was done by writing the name of a binary file in /lib/firmware to a sysfs entry. Have you thought about something like that? I don't know how practical/possible that would actually be with remoteproc
Jun 24 14:31:53 <Abhishek_> the previous 3.8.13 remoteproc can do that
Jun 24 14:31:53 <alexanderhiam> apaar__: what was the exact reason for changing to sending ints instead of chars?
Jun 24 14:32:16 <alexanderhiam> great
Jun 24 14:32:41 <alexanderhiam> I think that should definitely be added here as well then
Jun 24 14:36:55 <apaar__> alexanderhiam :i figured that people will mostly be moving values ie integers instead of characters.If someone wants characters they can just send ascii values and convert to char
Jun 24 14:38:10 <alexanderhiam> apaar_: another possibility would be to have a few different routines for different data types
Jun 24 14:38:36 <alexanderhiam> I could see a lot of cases where chars would make sense, like sending single byte commands
Jun 24 14:39:19 <alexanderhiam> e.g. writeChar(), writeInt(), etc.
Jun 24 14:39:49 <alexanderhiam> apaar__: it would also be good to have return codes on the userspace read/write routines (which would mean passing in a buffer pointer to read() instead of returning the read value)
Jun 24 14:41:45 <apaar__> alexanderhiam :i anyway have to allocate in 4 byte chunks so minimum buffer size will be 4 for char and 2 for int(excluding a empty buffer) but it is definatly doable,i will also change the userspace routine for the pointer and return values
Jun 24 14:42:16 <alexanderhiam> 2 for int?
Jun 24 14:42:29 <apaar__> int is 2 bytes so 2 values
Jun 24 14:42:50 <alexanderhiam> what int is 2 bytes?
Jun 24 14:43:14 <alexanderhiam> pru ints are 32-bit aren't they?
Jun 24 14:43:29 <alexanderhiam> as are the arm ints
Jun 24 14:43:43 <apaar__> i am using a uint16_t to increase number of values...
Jun 24 14:44:29 <alexanderhiam> apaar__: ah, so call it a uint16_t! That's very different that a signed 32-bit int
Jun 24 14:45:07 <alexanderhiam> and also a somewhat funny type to standardize on
Jun 24 14:46:03 <apaar__> alexanderhiam :P could i come back in a bit ,dinner time ...
Jun 24 14:46:47 <alexanderhiam> apaar_: another option would be to accept a void pointer and a number of bytes to send. The type is just the way the bytes are interpreted by the userspace and pru code, it really doesn't matter at the transport layer
Jun 24 14:47:04 <Abhishek_> apaar__: What if I sent a string?
Jun 24 14:47:54 <alexanderhiam> apaar__: no problem, I'll probably send you a few more thoughts, feel free to ignore them until after dinner
Jun 24 14:50:33 <alexanderhiam> apaar__: you could define: int write(uint8_t *buffer, uint8_t length) // write up to 255 bytes from buffer
Jun 24 14:52:00 <alexanderhiam> then use it like: int val = 5; write(&val, 4);
Jun 24 14:52:43 <alexanderhiam> or: uint16_t buf[LENGTH]; write(buf, sizeof(uint16_t)*LENGTH);
Jun 24 14:53:25 <alexanderhiam> or to avoid warnings: uint16_t buf[LENGTH]; write((uint8_t *)buf, sizeof(uint16_t)*LENGTH);
Jun 24 14:54:19 <alexanderhiam> apaar__: in other words you can have a single routine that can send whatever data type the user wants by breaking it into single bytes
Jun 24 14:56:27 <new2bbb> what is the meaning of step in ADC for BBB?
Jun 24 15:04:53 <apaar__> alexanderhiam : im back had a byte to eat :) some concerns on splitting into byte sized parts 1) writing can be done in bytes but how will a user reconstruct the data upon read this may involve passing of more data headers etc(not to sure) 2) will it not be easier to just convert character/string data into integers and decipher it on pru side for this i could take in a character pointer ,convert to int in userspace ,store in sysfs and then convert
Jun 24 15:04:53 <apaar__> back?
Jun 24 15:11:07 <alexanderhiam> apaar__: well, if the PRU and userspace code aren't already in agreement on what the data being sent is like then there will need to be some headers of some sort
Jun 24 15:11:46 <alexanderhiam> I guess the question is do you leave all the type and data length handling up to the user
Jun 24 15:12:24 <Abhishek_> wasn't the idea of pru-bridge to have a "serial-port" like communication channel between the userspace and the PRU?
Jun 24 15:14:22 <alexanderhiam> right, in which case it's just raw bytes
Jun 24 15:14:32 <apaar__> alexanderhiam :right now both pru and arm are both passing uint16_t with headers only for number of values to be read. it will be very easy to provide some character channels (say 3) and some seperate integer channels(remaining 2)
Jun 24 15:14:49 <shubhangi> alexanderhiam: i'll do it .. the firmware name from userspace .. suman anna gave me a hint as to how to implement that
Jun 24 15:15:06 <alexanderhiam> shubhangi: awesome
Jun 24 15:15:30 <Abhishek_> nice
Jun 24 15:15:38 <alexanderhiam> apaar__: I'm still not understanding the choice of uint16_t. If it's about byte alignment than I would think a regular int would make the most sense
Jun 24 15:16:42 <shubhangi> alexanderhiam ,Abhishek_ : the remoteproc driver expects a constant name pru-rproc0-fw .. the trick is to create a symlink between user provided fw and /lib/firmware/pru-rproc0-fw
Jun 24 15:17:50 <apaar__> alexanderhiam : i figured that the 700 odd values i will be getting with a 16 bit int compared to the 340 with int would prevent some loss of data if pru is inputing data faster than arm can read or vice versa
Jun 24 15:18:29 <apaar__> basically number of buffered values increases though max size storable reduces
Jun 24 15:19:27 <alexanderhiam> apaar__: I don't tink you should be thinking in terms of number of values. It's really about the number of bytes
Jun 24 15:19:54 <alexanderhiam> i.e. if each value the PRU is sending fits in a single byte then they should each be sent in a single byte
Jun 24 15:20:21 <ankur> anujdeshpande: hi
Jun 24 15:21:44 <alexanderhiam> if the PRU code is writing a single byte at a time I think it's fine to pack that into 32 bits. If the user is streaming single bytes quickly, I think it's ok to leave it up to them to buffer and pack into 32-bit blocks
Jun 24 15:22:43 <apaar__> alexanderhiam :i will then convert the channels back to char but not sure how we can reconstruct/pass integer values as that will be majority of the datatype beind passed or do i make it some channels char other int?
Jun 24 15:23:06 <Abhishek_> there's a "symlink" function for creating symlinks programmatically
Jun 24 15:23:45 <alexanderhiam> apaar__: see the example I gave earlier, the write routine can take a pointer and a number of bytes to send
Jun 24 15:24:18 <alexanderhiam> the read and write routines don't need to have any knowledge of the types being used in the user code
Jun 24 15:25:57 <apaar__> but will the pru and arm not have to know what data type is being passed?
Jun 24 15:26:27 <anujdeshpande> hey ankur
Jun 24 15:26:30 <apaar__> for write it is ok but in read on the other side i am not sure how it will work
Jun 24 15:27:06 <alexanderhiam> apaar__: you would just read the same number of bytes
Jun 24 15:28:32 <alexanderhiam> whether that means reading all the available bytes, or having a start and stop code, or a header that says the number of bytes being sent is a matter or implementation
Jun 24 15:29:06 <alexanderhiam> that could be handled by pru-bridge, or could be left up to the user to do
Jun 24 15:29:16 <apaar__> we can that up to the user right?ie for a 32 bit int they call read 4 times
Jun 24 15:29:51 <apaar__> cos headers could be very costly worst cse would be each byte has a 1 buyte to be read header doubling data
Jun 24 15:30:08 <alexanderhiam> apaar__: I would think they would call read one time, e.g. read(my_val, 4)
Jun 24 15:30:46 <apaar__> that would be fine i could internally just call read 4 times :)
Jun 24 15:32:06 <alexanderhiam> apaar__: what do you mean by call read? Read from the sysfs entry?
Jun 24 15:33:50 <apaar__> yes and read could return one byte at a time also on pru side a read of one byte can be called length number of times.This mean i dont have to worry about passing sizes/extra headers
Jun 24 15:34:13 <alexanderhiam> right
Jun 24 15:35:45 <apaar__> ok then i will revert to character buffers(uint8_t) but control buffer values/headers and head and tail will be uint16_t also i will try to get the userspace up in that form
Jun 24 15:39:10 <shubhangi> apaar__,alexanderhiam : the PRU framework writes and reads the way alexanderhiam suggested ... you can some i make use of it ..
Jun 24 15:40:06 <shubhangi> *changes to make
Jun 24 15:43:26 <moto-timo> buenas
Jun 24 15:45:49 <neemo> ello
Jun 24 15:46:15 <Abhishek_> 15mins to meeting
Jun 24 15:49:05 <nerdboy> moin
Jun 24 15:49:55 <anujdeshpande> av500: hendersa wont be able to make it today, busy in a meeting. he’s dropped a mail to me and ankur.
Jun 24 15:50:05 <neemo> nerdboy: seen the link?
Jun 24 15:50:14 <neemo> nerdboy: and mornin'
Jun 24 15:52:11 * vvu is here
Jun 24 15:52:20 <alexanderhiam> shubhangi: you mean the read write routines you have are single byte like that?
Jun 24 15:55:05 <nerdboy> neemo: your report?
Jun 24 15:55:21 <shubhangi> alexanderhiam: no.. routines take a buffer starting address and total size in bytes
Jun 24 15:55:39 <neemo> nerdboy: well, yeah, but the link in it is more interesting
Jun 24 15:55:43 <neemo> nerdboy: here -> http://nvisnjic.com/2015/06/24/2d-correction-in-action.html
Jun 24 15:55:45 <moto-timo> arianepaola_: ping
Jun 24 15:56:09 <shubhangi> alexanderhiam: data type doesnt matter .. user writing pru code must know what hes sending .. so similar routines at pru end
Jun 24 15:56:22 <vvu> azizulhakim: around here ?
Jun 24 15:56:37 <neemo> nerdboy: finished with the 2D estimator/corrector in matlab, now on to 3D and time-variant stuff
Jun 24 15:57:05 <_av500_> alohi
Jun 24 15:57:10 <_av500_> 3min to 5min
Jun 24 15:57:55 <_av500_> arianepaola_: report?
Jun 24 15:58:22 <Abhishek_> in some time I'll be going afk for dinner, if needed leave me a ping
Jun 24 15:58:44 <nerdboy> looks pretty good so far
Jun 24 15:59:47 <neemo> yeah, the 2D correction works extremely good in simulation
Jun 24 16:00:08 <neemo> now to port it and test how that holds up with real sensors
Jun 24 16:02:59 <nerdboy> real data should be more fun...
Jun 24 16:03:11 <alexanderhiam> shubhangi: awesome. apaar__: take a look at that. That's probably a good place to start in thinking about how pru-bridge and the framework will work together
Jun 24 16:04:22 <apaar__> alexanderhiam : will look into it in a bit
Jun 24 16:05:52 <neemo> nerdboy: yup, looking forward to it
Jun 24 16:06:09 <ds2> hmmmm
Jun 24 16:06:13 <neemo> gonna finish the 3axis and telemetry inputs in Octave first
Jun 24 16:06:14 <_av500_> looks like time to start
Jun 24 16:06:22 <_av500_> 1) Welcome everybody
Jun 24 16:06:23 <vvu> hip hip hurray!
Jun 24 16:06:34 <_av500_> do we have all our students?
Jun 24 16:06:35 <ankur> hi
Jun 24 16:06:37 <shubhangi> hey
Jun 24 16:06:38 <neemo> hello
Jun 24 16:06:40 <rohith> here
Jun 24 16:06:44 <ebadawy> here
Jun 24 16:06:47 <azizulhakim_> here
Jun 24 16:06:55 <apaar__> here
Jun 24 16:07:10 <_av500_> moto-timo: any idea about arianepaola_ ?
Jun 24 16:07:19 <_av500_> hi everybody
Jun 24 16:07:19 <nerdboy> someone is fashionably late?
Jun 24 16:07:28 <moto-timo> _av500_: no contact since last wednesday
Jun 24 16:07:33 <_av500_> :(
Jun 24 16:07:38 <moto-timo> :(
Jun 24 16:07:48 <_av500_> moto-timo: could you fire off a mail?
Jun 24 16:07:52 <arianepaola_> hello :)
Jun 24 16:07:55 <ds2> we losr one?
Jun 24 16:07:55 <_av500_> ah
Jun 24 16:07:59 <ds2> lost
Jun 24 16:08:00 <_av500_> ds2: no
Jun 24 16:08:01 <neemo> bingo
Jun 24 16:08:06 <_av500_> hi arianepaola_
Jun 24 16:08:16 <arianepaola_> hey
Jun 24 16:08:20 <nerdboy> we would send a search part if necessary
Jun 24 16:08:31 <_av500_> arianepaola_: mising your report
Jun 24 16:08:33 <nerdboy> with search drones even
Jun 24 16:08:35 <_av500_> missing
Jun 24 16:09:03 <ds2> might lose access.. on flaky wifi via android :(
Jun 24 16:09:13 <_av500_> ds2: noted
Jun 24 16:09:24 <arianepaola_> I will send it
Jun 24 16:09:44 <_av500_> arianepaola_: thansk
Jun 24 16:10:17 <ds2> av500: quick q - do students need multiple mentor reviews thid year or just one from primary?
Jun 24 16:10:20 <nerdboy> +y
Jun 24 16:10:28 <_av500_> ds2: one should be ebough
Jun 24 16:10:30 <_av500_> enough
Jun 24 16:10:41 <_av500_> 2) reports
Jun 24 16:10:46 <ds2> ok. carol was unclear
Jun 24 16:10:49 <_av500_> we have 7 and one is incomming
Jun 24 16:10:54 <_av500_> ds2: I'll have a look
Jun 24 16:11:13 <_av500_> but I think google is still very much one.mentor oriented
Jun 24 16:11:45 <_av500_> jkridner: you here?
Jun 24 16:11:52 <_av500_> 3) midterms
Jun 24 16:11:59 <_av500_> midterms come sooner than you think
Jun 24 16:12:11 <_av500_> the eval period starts in two days
Jun 24 16:12:36 <neemo> _av500_: Friday + 10 days?
Jun 24 16:12:39 <neemo> is the period
Jun 24 16:12:41 <_av500_> yes
Jun 24 16:12:43 <_av500_> until the 3rd
Jun 24 16:12:56 <_av500_> so you can get roughly one more week in
Jun 24 16:12:57 <vvu> perfect...will do it this weekend
Jun 24 16:13:14 <_av500_> I'll send mentors a mail soon
Jun 24 16:13:29 <_av500_> I guess all students are in full steam anyway
Jun 24 16:13:32 <neemo> ok, thanks, will have testable stuff until next week
Jun 24 16:13:38 <shubhangi> _av500_: so today's evaluation put off till next week ?
Jun 24 16:13:44 <ds2> include name of who for which student please
Jun 24 16:13:48 <ebadawy> _av500_ jkridner: there is still one week left, should I submit what is done so far or wait till i finish with next week work?
Jun 24 16:14:03 <_av500_> you can alwas update it until the cutoff
Jun 24 16:14:13 <ebadawy> okay
Jun 24 16:14:21 <_av500_> dont wait until the last minute
Jun 24 16:14:25 <jkridner> ebadawy: I agree with _av500_
Jun 24 16:15:08 <_av500_> 4) any open issues not in the reports?
Jun 24 16:15:15 <_av500_> any blocking points?
Jun 24 16:15:28 <jkridner> _av500_: yes, I'm here.
Jun 24 16:15:48 <_av500_> apaar__: ankur rohith ebadawy neemo arianepaola_ shubhangi
Jun 24 16:15:56 <ebadawy> I'm OK
Jun 24 16:16:00 <apaar__> nope
Jun 24 16:16:06 <shubhangi> nopes
Jun 24 16:16:09 <ankur> no problem
Jun 24 16:16:13 <neemo> no blockers, we'll see about sensors next week
Jun 24 16:16:23 <azizulhakim> i'm okay
Jun 24 16:17:07 <_av500_> arianepaola_: rohith ?
Jun 24 16:17:10 <rohith> _av500_: Mentioned in the report. Midterm goal is still quite some way to go...
Jun 24 16:17:24 <vvu> azizulhakim: i saw smth about ffmpeg on github...
Jun 24 16:17:40 <_av500_> vvu: later please
Jun 24 16:17:53 <_av500_> arianepaola_: you there?
Jun 24 16:17:58 <_av500_> rohith: unerstood
Jun 24 16:18:01 <_av500_> under*
Jun 24 16:18:51 <shubhangi> _av500_: you were going to look at progress up till now for 2 students at a time.
Jun 24 16:19:05 <_av500_> yes
Jun 24 16:19:11 <_av500_> its not a formal thing
Jun 24 16:19:12 <shubhangi> azizulhakim and mine
Jun 24 16:19:19 <_av500_> more like sharing of your work with others
Jun 24 16:19:30 <shubhangi> when does that start
Jun 24 16:19:38 <_av500_> in 3 minutes?
Jun 24 16:19:43 <shubhangi> oh
Jun 24 16:19:44 <shubhangi> :)
Jun 24 16:19:48 <shubhangi> okay
Jun 24 16:20:06 <_av500_> seems we lost arianepaola_
Jun 24 16:20:10 * nerdboy starts the egg timer
Jun 24 16:21:09 <_av500_> ok, lets move on
Jun 24 16:21:13 <_av500_> 5) Open Stage
Jun 24 16:21:23 <_av500_> shubhangi: you want to start?
Jun 24 16:21:32 <shubhangi> _av500_: sure :)
Jun 24 16:22:25 <shubhangi> Project name: PRUSS support for newer kernels. GitHub : https://github.com/shubhi1407/PRU-framework
Jun 24 16:23:23 <shubhangi> what it does : a light weight communication framework between PRU and ARM for kernel version 3.14 and above
Jun 24 16:23:44 <shubhangi> we already have panto rproc for 3.8 but a lot of things have changed since then
Jun 24 16:24:01 <shubhangi> most notably there is no capemgr
Jun 24 16:24:32 <shubhangi> so you cant dynamically load/unload dtbs ..
Jun 24 16:24:45 <ds2> it id back in 4.x
Jun 24 16:24:52 <ds2> it is
Jun 24 16:25:06 <shubhangi> oh .. havent tried that.. thanks
Jun 24 16:25:27 <alexanderhiam> shubhangi: yes, what ds2 said. You should definitely be targeting that as well
Jun 24 16:25:40 <shubhangi> starting point of project : ti's remoteprc driver
Jun 24 16:25:56 <shubhangi> alexanderhiam: okay .. i'll testing the driver on 4.x this week
Jun 24 16:26:07 <rcn-ee> most of what's in ti's 3.14.x is either in 4.1 or heading there. ;)
Jun 24 16:26:08 <shubhangi> and compatibility issues as well
Jun 24 16:27:25 <shubhangi> basic flow of driver : register remote processor's as platform devices with the kernel
Jun 24 16:27:31 * vmayoral|pc blames his bad connection
Jun 24 16:28:05 <shubhangi> request irqs and io memory for devices
Jun 24 16:28:47 <shubhangi> register your processor with the core remoteproc infrastructure provided by linux
Jun 24 16:29:47 <shubhangi> by now you have 8 interrupts registered and a handler for them in the driver and address to PRU memories so can read/write from them
Jun 24 16:30:15 * jkridner is off of phone distractions now
Jun 24 16:30:42 <_av500_> shubhangi: is ther also rpmsg to talk to the PRU?
Jun 24 16:30:43 <shubhangi> firmware loading handled by the core remoteproc and so is shutdown/boot
Jun 24 16:30:55 <shubhangi> _av500_: coming to it
Jun 24 16:31:57 * jkridner looks at github
Jun 24 16:32:23 <shubhangi> the driver exposes interrupts to userspace via polling to sysfs attr
Jun 24 16:33:08 <shubhangi> you can also read/write to PRU memories from user routines provided in userlibrary
Jun 24 16:33:49 <shubhangi> user can also send sys events to PRU 0-63 from userspace
Jun 24 16:34:22 <shubhangi> wait for events from PRU, register callback function to be called if interrupt is recieved
Jun 24 16:34:41 <ds2> having somw userspace vs k space benchmarkd would be good
Jun 24 16:35:33 <shubhangi> as for rpmsg, the kernel space code is partially implemented
Jun 24 16:35:54 <ds2> gotta bail.... email me if anyone needs me for the time being
Jun 24 16:36:27 <_av500_> k
Jun 24 16:36:30 <_av500_> thx
Jun 24 16:36:32 <shubhangi> for PRU end, i need to figure out how to keep it small in size
Jun 24 16:36:46 <nerdboy> shubhangi: are you using libsysfs interface?
Jun 24 16:36:49 <shubhangi> the code size,
Jun 24 16:37:42 <shubhangi> nerdboy: not as of now
Jun 24 16:38:02 <shubhangi> nerdboy: i am accessing through fds .. pretty raw
Jun 24 16:38:32 <shubhangi> tried libudev .. you suggest i should use libsysfs ?
Jun 24 16:38:35 <nerdboy> fine for initial testing i guess
Jun 24 16:38:55 <nerdboy> that would be the "proper" interface
Jun 24 16:39:12 <shubhangi> hmm .. will do
Jun 24 16:39:51 <shubhangi> so if anyone wants to try the code and has 3.14 running on their BBB
Jun 24 16:39:59 <shubhangi> the repo has all build instructions
Jun 24 16:40:30 <shubhangi> cleaned everything up for today
Jun 24 16:40:41 <_av500_> nice
Jun 24 16:40:49 <_av500_> shubhangi: is there some "demo" PRU code to run?
Jun 24 16:40:55 <_av500_> something that blinks a LED?
Jun 24 16:41:03 <nerdboy> rcn-ee: pushing the last stuff to 4.1 might be finished when?
Jun 24 16:41:08 <shubhangi> _av500_: yes, check the repo
Jun 24 16:41:12 <_av500_> ok, will do :)
Jun 24 16:41:21 <_av500_> shubhangi: thanks for the report
Jun 24 16:41:30 <shubhangi> thanks :)
Jun 24 16:41:41 <rcn-ee> nerdboy, 4.1.0 should be in the repo's as of last night/this monring..
Jun 24 16:41:54 <_av500_> azizulhakim: you're up, you have the stage
Jun 24 16:42:11 <azizulhakim> _av500_: thanks :)
Jun 24 16:42:36 <azizulhakim> Project: Android-based Remote Display
Jun 24 16:42:44 <azizulhakim> Code: https://github.com/azizulhakim/beagleusb
Jun 24 16:42:44 <nerdboy> rcn-ee: don't suppose i can get a patch tarball?
Jun 24 16:42:56 <_av500_> nerdboy: rcn-ee : shhh!
Jun 24 16:43:11 <nerdboy> you started too soon...
Jun 24 16:43:32 * nerdboy goes into wait mode
Jun 24 16:43:52 <azizulhakim> The idea is to create a usb device driver and android application to replace lcd cape, input devices, audio devices with a single android device
Jun 24 16:44:35 <azizulhakim> The display driver was done by praveendath92, I'm mostly working on audio driver and input driver parts
Jun 24 16:45:54 <azizulhakim> So far I'm almost done with the input and audio driver parts
Jun 24 16:46:11 <azizulhakim> Now the main concern is the USB bandwidth
Jun 24 16:46:35 <_av500_> you could drop audio to mono if needed
Jun 24 16:46:56 <azizulhakim> So I'm trying to find out some efficient compression technique to overcome the bandwidth problem
Jun 24 16:47:16 <_av500_> pointer and keyboard work?
Jun 24 16:47:39 <azizulhakim> yes, pointer and keyboard works
Jun 24 16:48:01 <azizulhakim> also the bandwidth is main concern for display driver
Jun 24 16:48:09 <_av500_> right
Jun 24 16:48:28 <_av500_> what raw USB bandwidth do you get?
Jun 24 16:48:31 <azizulhakim> playing a media file requires a lot of bandwidth
Jun 24 16:48:39 <nerdboy> keyboard meaning android input device?
Jun 24 16:49:06 <_av500_> azizulhakim: understood
Jun 24 16:49:13 * nerdboy could dig out nexus phone for testing
Jun 24 16:49:20 <azizulhakim> I had some test before and I think its 4 times slower than it should be
Jun 24 16:49:20 <_av500_> but thats probably better done on android anyway
Jun 24 16:50:01 <_av500_> azizulhakim: it would be interesting to know the raw speed
Jun 24 16:50:16 <_av500_> before you hunt for the best compression
Jun 24 16:50:49 <azizulhakim> ok, i'll check. i did this before but don't remember exactly
Jun 24 16:51:37 <azizulhakim> build instructions are added in the doc folder of the source code
Jun 24 16:51:58 <azizulhakim> corresponding android app: https://github.com/azizulhakim/bard-droid
Jun 24 16:52:06 * moto-timo needs to leave for a meeting
Jun 24 16:52:12 <_av500_> moto-timo: ok
Jun 24 16:52:16 <azizulhakim> That's so far from me :)
Jun 24 16:52:21 <_av500_> azizulhakim: thank you
Jun 24 16:52:30 * nerdboy needs to convert those docs to rSt
Jun 24 16:52:33 <azizulhakim> :)
Jun 24 16:52:37 <vvu> azizulhakim: trying to see how ffmpeg does compression ?
Jun 24 16:52:41 <_av500_> before we forget, who's up for next week?
Jun 24 16:53:10 <_av500_> ankur: rohith neemo arianepaola_ apaar__ ebadawy
Jun 24 16:53:26 <ebadawy> add me to the list :)
Jun 24 16:53:33 <_av500_> +1
Jun 24 16:53:49 * apaar__ would not mind going next
Jun 24 16:53:54 <_av500_> ok
Jun 24 16:53:56 <azizulhakim> vvu: more like how to use it. if ffmpeg  gives decent compression + processing time
Jun 24 16:54:04 <_av500_> ebadawy and apaar__ for next week
Jun 24 16:54:05 <azizulhakim> it would be nice to use it
Jun 24 16:54:07 <neemo> I'm ok as well
Jun 24 16:54:23 <_av500_> neemo: maybe wecan fit three
Jun 24 16:54:27 <nerdboy> you'd be better with the libav code
Jun 24 16:54:30 <vvu> but be sure you can integrate it ok in kernel space and no licensing issues
Jun 24 16:54:33 <_av500_> keeping you on the list
Jun 24 16:54:44 <neemo> _av500_: Ok
Jun 24 16:55:02 <neemo> I'll try to finish testing with real data before Wednesday then
Jun 24 16:55:15 <_av500_> ok
Jun 24 16:55:21 * neemo needs to find a reference magnetometer hmmm
Jun 24 16:55:25 <azizulhakim> vvu: okay. do you know if any other compression library ?
Jun 24 16:55:27 <nerdboy> libav is missing a little bit of functionality but also missing the wonky code from ffmpeg
Jun 24 16:55:37 <vvu> av500: ^
Jun 24 16:55:45 <_av500_> vvu: :)
Jun 24 16:55:53 <_av500_> lets finish the meeting
Jun 24 16:55:59 <_av500_> and then I have to run :)
Jun 24 16:56:10 <_av500_> 6) or 7)? Anything else?
Jun 24 16:56:22 <_av500_> otherwise, thanks for attending
Jun 24 16:56:24 <shubhangi> midterms when exactly ?
Jun 24 16:56:32 <_av500_> shubhangi: eval starts in 2 days
Jun 24 16:56:34 <_av500_> until the 3rd
Jun 24 16:56:37 <shubhangi> okay
Jun 24 16:56:39 <shubhangi> thanks :)
Jun 24 16:56:40 <jkridner> azizulhakim: is touchscreen input part of your project?
Jun 24 16:56:46 <_av500_> dont wait until the laast minute to submit
Jun 24 16:57:06 <azizulhakim> jkridner: yes
Jun 24 16:57:59 * jkridner finds it in your comments (focus on input and audio, almost done but need to work on USB bandwidth)
Jun 24 16:58:27 <nerdboy> overall libav code is much better
Jun 24 16:59:05 <_av500_> ok everybody, thanks for attending, I need to go
Jun 24 16:59:17 <shubhangi> bye
Jun 24 16:59:18 <alexanderhiam> thanks _av500_!
Jun 24 16:59:19 * jkridner waves
Jun 24 16:59:22 <neemo> thank you
Jun 24 16:59:23 <_av500_> \o/
Jun 24 16:59:27 <ebadawy> THANKS
Jun 24 16:59:58 * nerdboy would like more mtgs with this much enthusiasm
Jun 24 17:00:31 * alexanderhiam would like to see this much enthusiasm in here every day
Jun 24 17:00:38 <nerdboy> pissy engineering/project meetings suck the big schween...
Jun 24 17:01:36 * nerdboy surprised at the apparent correlation between "professional" and "just-plain-pissy"
Jun 24 17:02:18 <rcn-ee> nerdboy, https://rcn-ee.com/deb/sid-armhf/v4.1.0-bone9/ ;)
Jun 24 17:04:46 <nerdboy> last time i packaged up bone-sources there were a butt-load of patches...
Jun 24 17:05:03 <rcn-ee> nerdboy, don't forget to update gentoo's dtc: https://github.com/pantoniou/dtc/tree/dt-overlays5 (if you want to build local *.dtbo's)
Jun 24 17:05:32 <rcn-ee> nerdboy, oh patches: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.1/patches ;)
Jun 24 17:05:59 <nerdboy> sys-apps/dtc-1.4.1-r1:0  <=  i need newer than that?
Jun 24 17:06:17 <rcn-ee> so new, it hasn't been pushed to dtc's git..
Jun 24 17:06:39 <rcn-ee> but note, 3.8's dtc is not compabile with 4.1's dtc for overlays..
Jun 24 17:11:19 <rcn-ee> nerdboy, my 4.1.x overlay patchset is 2 down as of last night for v4.2.x .;) hopes the rest make it in. ;)
Jun 24 17:17:52 <alexanderhiam> neemo: can you get some code pushed to github soon?
Jun 24 17:18:33 <alexanderhiam> neemo: you should really be showing your progress by pushing code regularly
Jun 24 17:20:26 <neemo> alexanderhiam: I'll be pushing the MATLAB stuff tomorrow, eg. when I clean it up a bit
Jun 24 17:20:46 <neemo> adding the 3axis part through the day
Jun 24 17:21:04 <alexanderhiam> ok. The sooner you get anything pushed the better
Jun 24 17:21:13 <neemo> k, will keep it in mind
Jun 24 17:21:30 <alexanderhiam> do you have any of the framework code written? i.e. API outline, etc.
Jun 24 17:21:35 <neemo> didn't think of pushing anything that can't be tested by other people right off the bat
Jun 24 17:21:52 <alexanderhiam> it's the only way we can know that you're on track
Jun 24 17:22:01 <neemo> yeah, makes sense
Jun 24 17:22:26 <neemo> didn't work on the API much, was focusing on getting something testable with the hardware and algorithm asap
Jun 24 17:22:57 <neemo> was focusing on transfering stuff from research papers to code that can actually be used
Jun 24 17:23:41 <neemo> which I'm gonna test on real data within the week and get similar results as in the simulated dataset(or so I hope!)
Jun 24 17:23:50 <alexanderhiam> ok. It would be ideal if you could have some framework code written by midterm as well. It doesn't have to all be implemented, more just to show that you have a good plan for how it all fits together
Jun 24 17:24:20 <neemo> ok, I'll be on it
Jun 24 17:24:26 <alexanderhiam> great
Jun 24 17:24:37 <neemo> gonna wrap up the octave sutff and put it in the BBB first
Jun 24 17:24:44 <alexanderhiam> ok
Jun 24 17:24:47 <neemo> so I have a real world test for the midterm
Jun 24 17:25:28 <neemo> also nerdboy alexanderhiam -> any ideas on a stable test environment
Jun 24 17:25:45 <alexanderhiam> for physical testing with sensors?
Jun 24 17:25:48 <neemo> eg. I should have a mostly static magnetic field to test the measurements on
Jun 24 17:25:51 <neemo> yeah
Jun 24 17:25:56 * karki_ wonders.....      https://plus.google.com/+GuidoStepken/posts/jpVpbEu4WE8
Jun 24 17:26:10 <alexanderhiam> hmm... that is a bit tricky
Jun 24 17:26:24 <neemo> the more finer testing will be done later, I'll build a pair of Helmholtz coils for the test, probably after the GSoC
Jun 24 17:26:44 <neemo> now I just have to have something mostly stable, and get a measurement of the magnitude of the field in that space
Jun 24 17:27:28 <neemo> so I'll buy a handheld magnetometer from Taobao I guess, and get the magnitude from there (need it for the fitting algorithm) and try to find a quite place where I can do the first tests
Jun 24 17:27:34 <neemo> or that's my current thinking
Jun 24 17:27:54 <nerdboy> build a faraday-chicken-coop
Jun 24 17:28:41 <neemo> will that work? I mean, it will isolate outside stuff good, but It'll isolate the earths magnetic field as well, no?
Jun 24 17:28:47 <nerdboy> so yeah, you should have some kind of interface defined
Jun 24 17:29:29 <neemo> I could put the sensor in a faraday cage and put a couple of coils in to produce an artificial field (one to measure, one on the sensor for controlled interference
Jun 24 17:29:36 <nerdboy> can't really a proper spec with C headers but think of it more like an Ada spec
Jun 24 17:29:42 <nerdboy> *do even
Jun 24 17:30:16 <alexanderhiam> neemo: at this point coding should probably be a higher priority than accurate testing and calibration,  it is the google summer of code after all!
Jun 24 17:30:43 <nerdboy> at least you can do a top-level include spec with actual doxygen comments and everything
Jun 24 17:31:24 <nerdboy> yup, "good enough" is fine
Jun 24 17:31:25 <neemo> I agree, though I've heard testing is important as well ( nerdboy ) and ideally both should be representable by the midterm
Jun 24 17:31:31 <apaar__> alexanderhiam :i implemented the uint8_t buffers and userspace read and write have been made byte oriented and work(i have pushed to github but needs a little more testing) :)
Jun 24 17:31:51 <nerdboy> you can write tests against your spec if it's decent...
Jun 24 17:32:08 <alexanderhiam> apaar__: awesome
Jun 24 17:32:21 <nerdboy> other stuff you can put in a test plan doc
Jun 24 17:32:34 <neemo> nerdboy: alexanderhiam : Ok, I'll wrap up the Octave simulations and think about some easy to do tests
Jun 24 17:32:44 <alexanderhiam> great
Jun 24 17:33:00 <neemo> nerdboy, alexanderhiam: and I'll look into the API a bit more and work on that
Jun 24 17:33:24 <neemo> expect a lot of pinging, while I try to figure out a best way to do it :)
Jun 24 17:33:33 <neemo> nerdboy alexanderhiam  ^
Jun 24 17:33:33 <nerdboy> so octave is good, use .m code to drive your api interface/code structure
Jun 24 17:33:50 <apaar__> alexanderhiam :a issues has shot up https://github.com/Apaar/PRU-Bridge/blob/master/userspace/pru_bridge.c#L91 gives a "expected 'uint8_t *' but argument is of type 'int *'" warning but that will remain if we want to pass different types :(
Jun 24 17:33:55 <alexanderhiam> yes, please do ask if you're unsure about implementation
Jun 24 17:34:16 <nerdboy> i little bit of time thinking about/documenting the interface is a good investment
Jun 24 17:34:21 <alexanderhiam> apaar__: just cast it to a uint8_t*
Jun 24 17:34:27 <neemo> nerdboy: ok, should I do the tests with Octave then? I can port to C/C++ later on
Jun 24 17:34:59 <alexanderhiam> apaar__: i.e. pru_write(1, (uint8_t *)data, 4);
Jun 24 17:35:13 <alexanderhiam> neemo: which tests?
Jun 24 17:35:16 <apaar__> alexanderhiam :but that is part of the user using the pru_bridge api they will have to do that every time :(
Jun 24 17:35:22 <nerdboy> as long as it makes a good working specification/test set and doesn't take too long
Jun 24 17:35:56 <neemo> alexanderhiam: tests for the correction algorithms with actual hardware readouts
Jun 24 17:36:12 <nerdboy> use your headers for documentation and make API docs with doxygen
Jun 24 17:36:14 <alexanderhiam> apaar__: it's C, that's pretty standard
Jun 24 17:36:38 <neemo> alexanderhiam: eg. plugging in sensor reads I get from the hardware through the Matlab/Octave code I've got so far and see how good correction is on real data
Jun 24 17:36:42 <alexanderhiam> neemo: that you currently have implemented in Octave? Either way I guess
Jun 24 17:36:48 <apaar__> ok cool so users will need a heads up on that in the documantation but it works anyway :)
Jun 24 17:36:58 <alexanderhiam> apaar__: right
Jun 24 17:38:56 <apaar__> alexanderhiam :what is i use void* to recieve and then cast it as uint8_t* within the method ,that should do it right?
Jun 24 17:39:14 <apaar__> if*
Jun 24 17:39:43 <nerdboy> neemo: your wiki thing is still empty
Jun 24 17:40:01 <alexanderhiam> apaar__: gcc will still give a warning
Jun 24 17:40:12 <alexanderhiam> I think taking a uint8_t* is better
Jun 24 17:40:19 <apaar__> :( ok cool
Jun 24 17:40:23 <alexanderhiam> I gotta run for a bit
Jun 24 17:40:29 <nerdboy> maybe add some status/doc stubs
Jun 24 17:41:53 <apaar__> alexanderhiam :just tried it no warning :)
Jun 24 17:41:57 <neemo> nerdboy: wiki?
Jun 24 17:42:04 <neemo> nerdboy: the one at elinux.org?
Jun 24 17:42:08 <nerdboy> meaning some of the stuff we just talked about, test approach, transition from .m files to C, etc
Jun 24 17:43:24 <neemo> nerdboy: ^
Jun 24 17:43:42 <nerdboy> what were you going to put there?
Jun 24 17:43:57 <nerdboy> github wiki pages also work...
Jun 24 17:44:02 <neemo> I was actually gonna redirect it to github/wiki
Jun 24 17:44:03 <neemo> yeah
Jun 24 17:44:27 <neemo> it currently points to my (username) page on elinux, just as a placeholder
Jun 24 17:44:58 <nerdboy> maybe elinux should point at current stuff then
Jun 24 17:45:04 <neemo> gonna write up more stuff on github/wiki when I push the code and link it back to my website for the longer explanations
Jun 24 17:45:57 <neemo> should I delete than entry then until I write up the github/wiki
Jun 24 17:45:58 <neemo> ?
Jun 24 17:46:09 <neemo> s/than/that
Jun 24 17:46:34 <nerdboy> <shrug>
Jun 24 17:47:16 <nerdboy> flip a coin?  just make sure stuff points to the right places for current work/docs
Jun 24 17:47:59 <neemo> ok
Jun 24 17:48:08 <neemo> the blog is up currently to track progress
Jun 24 17:48:55 <nerdboy> i'd document the testing/api design/other stuff on github wiki then
Jun 24 17:48:56 <neemo> I'll link the wiki to github/wiki for current docs and push the work up to github
Jun 24 17:49:02 <neemo> y
Jun 24 17:49:35 <nerdboy> make a few page stubs with some outline-y stuff
Jun 24 17:50:39 <neemo> will do
Jun 24 17:51:00 <neemo> I'll look into it tomorrow after I'm done with the 3-axis part
Jun 24 17:51:13 <nerdboy> that plus a draft top-level api header with some nice doxygen comments
Jun 24 17:52:28 <neemo> kk
Jun 24 17:52:53 * neemo hasn't used doxygen, goes to do some learning
Jun 24 17:52:57 <nerdboy> https://github.com/sarnold/medians-1D/blob/master/medians_1D.h  <=  cheesy example
Jun 24 17:56:02 <nerdboy> here's what it looks like after processing (not the most recent version of doxygen)
Jun 24 17:56:16 <nerdboy> http://www.gentoogeek.org/files/median/medians__1_d_8h.html
Jun 24 18:00:27 <neemo> very readable
Jun 24 18:00:54 <nerdboy> it's not a big deal, mostly just special comment tags (and a lot of free analysis depending on language and how the code is written)
Jun 24 18:01:46 <nerdboy> config file is well-commented or you can use doxyconfig gui
Jun 24 18:02:02 <neemo> I'll install doxygen and see where I go from there
Jun 24 18:02:09 <neemo> I'll ping you when I start working with it
Jun 24 18:02:22 <neemo> think the CLI will do fine
Jun 24 18:02:40 <nerdboy> the diagrams get much better with OO languages (and reasonably well-written code)
Jun 24 18:03:05 * neemo needs to update his systems, will visit the local coffee shop
Jun 24 18:03:18 <nerdboy> gui has nice tooltip explanations of settings
Jun 24 18:04:02 <nerdboy> you can actually get free graphs of your source code structure
Jun 24 18:04:30 <nerdboy> inheritance diagrams, collaboration diagrams, etc
Jun 24 18:04:32 <neemo> ok, I'll take that to heart and will roll with it
Jun 24 18:04:54 <neemo> huh, I have doxygen installed already, well that solves the coffee shop visit
Jun 24 18:05:07 <nerdboy> documenting the interfaces is up to you...
Jun 24 18:06:32 <neemo> I'll finish the MATLAB/Octave part and I'll ping you guys when i start working on the API
Jun 24 18:06:48 <nerdboy> with straight C all you get is basic include/call graphs
Jun 24 18:07:04 <nerdboy> mostly
Jun 24 18:07:17 <neemo> When I get to a reasonable design, I'll work with doxygen to document it
Jun 24 18:07:50 <neemo> and reiterate until we have something workable
Jun 24 18:07:51 <nerdboy> start with top-level .h file if you're using C
Jun 24 18:08:04 <neemo> ok
Jun 24 18:08:15 <nerdboy> don't need implementation to document/define interface
Jun 24 18:08:55 <nerdboy> meaning start with doxygen tags/descriptions from the get-go
Jun 24 18:09:43 <nerdboy> that the header files/other source code generate current docs with every build
Jun 24 18:09:52 <nerdboy> *that way even
Jun 24 18:10:47 <nerdboy> in general, don't wait to do something like that...
Jun 24 18:10:53 <neemo> makes sense, doxygen it is then
Jun 24 18:12:32 <neemo> ok, I'm off to bed for today, but I'll report back tomorrow with MATLAB stuff and start working on defining the interface
Jun 24 18:13:00 <nerdboy> we'll add a "make docs" target for that...
Jun 24 18:13:26 <neemo> hopefully I'll be done with everything MATLAB/Octave related by Friday so I can focus on testing & interface from then onwards
Jun 24 18:13:54 <nerdboy> plus you will be updating your API comments as you go...
Jun 24 18:14:12 <nerdboy> *doxy comments that generate API docs
Jun 24 18:14:39 * nerdboy sincerely hopes other people are listening too
Jun 24 18:14:57 <neemo> ok, keeping that in mind
Jun 24 18:15:07 <neemo> documentation is king
Jun 24 18:15:17 <nerdboy> doxygen should be one of your best friends...
Jun 24 18:15:19 <neemo> testing is queen then ?
Jun 24 18:15:55 <neemo> aaanyway, I'll be getting acquainted with my new best friend
Jun 24 18:16:32 <neemo> but first, hitting the sack
Jun 24 18:16:40 * nerdboy just saw some discussion of markdown support on dev ml
Jun 24 18:16:54 <nerdboy> didn't even know that was in there...
Jun 24 18:18:29 <neemo> dev machine learning?
Jun 24 18:24:28 <nerdboy> doxygen-develop mailing list...
Jun 24 18:24:54 <neemo> makes much more sense
Jun 24 18:25:15 <neemo> anyway good night everyone
Jun 24 18:25:21 <neemo> catch you tomorrow
Jun 24 18:26:36 <Abhishek_> shubhangi: Can you extract the PRU section from the 3.14 kernel and try to create an overlay?
Jun 24 18:29:20 * nerdboy also surprised more people don't eat their own (doc) dogfood, periodically repeating "crap, i gotta make better docs!!"
Jun 24 18:30:30 * nerdboy had to dig his own docs out of the wayback machine after web server died a few weeks ago
Jun 24 20:35:53 <apaar_> alexanderhiam :void* works no warnings :)
Jun 25 00:24:43 <ebadawy> jkridner: I don't know how to mention the license, could u tell me what should I do? https://github.com/ehab93/bone101/commit/6d7a298bb483fd5c4411a05d32f72d91334edef7
Jun 25 00:25:59 <ebadawy> anybody ^
Jun 25 00:30:41 <rcn-ee> ebadawy, did you get it from somewhere, or did you write it yourself?
Jun 25 00:31:38 <ebadawy> rcn-ee: I got it from here https://github.com/kenwheeler/slick
Jun 25 00:35:44 <rcn-ee> add: https://github.com/kenwheeler/slick/blob/master/LICENSE  as "slick.LICENSE" in the slick dir.. make sure to add a slick.SOURCE pointing back to his repo. ;)
Jun 25 00:36:41 <rcn-ee> (it makes it helpful for maintaince when the next user needs to update "slick")
Jun 25 00:37:15 <ebadawy> rcn-ee: u mean add it as a submodule ?
Jun 25 00:37:27 <rcn-ee> nah, stay away from submodules.. ;)
Jun 25 00:38:13 <ebadawy> that what jkridner said !
Jun 25 00:38:27 <ebadawy> so how to point it back to the repo then?
Jun 25 00:38:54 <rcn-ee> the problem with submodules... the version of git in wheezy, pukes on them...
Jun 25 00:39:34 <ebadawy> but I found it very useful however in getting things always up-to-date
**** ENDING LOGGING AT Thu Jun 25 02:59:59 2015