**** BEGIN LOGGING AT Fri May 06 02:59:58 2016 May 06 03:44:58 Hey Wormo ! May 06 03:45:55 ds2: Wormo : I have added the project to elinux page. Please check the mentor name there, if i should make some changes. May 06 03:46:23 I have just copied the mentor list as is written on google result link, in the same order. May 06 04:20:44 ZeekHuge, I saw, noticed you completed it even before exam was done May 06 04:21:00 :) May 06 04:21:14 Wormo: Is the name correct ? May 06 04:21:34 I mean .. should i mention the complete names or it is okay ? May 06 04:21:36 that's fine, but probably should rearrange since I'm not "primary" mentor May 06 04:22:24 I just copy pasted as was given here https://summerofcode.withgoogle.com/projects/#5391975498907648 May 06 04:23:04 I think that's because I clicked the mentor link first :) May 06 04:25:26 Okay so Abhishek's name first ? May 06 04:25:37 ds2: ^^ May 06 04:26:20 ? May 06 04:26:33 if you mean the naming thing... I don't have an opinion May 06 04:26:43 Okay. May 06 04:28:32 I am not actually sure about the naming sequence, neither I know if that is imp, so if there's a mistake, please let me know and I will correct it :) May 06 04:29:38 *shrug* this isn't an academic paper May 06 12:30:13 alexhiam: no word from amr? I'm going to shut down to head into the office now. May 06 14:04:07 I really need to get this ... May 06 14:04:23 Why are the kernel images all so different from each other ? May 06 14:04:47 and so uneasy to understand May 06 14:05:02 kernel images = kernel images for beaglebone May 06 14:05:40 now I downloaded and installed Linux beaglebone 4.4.8-ti-r22 #1 SMP Wed Apr 27 22:23:10 UTC 2016 armv7l GNU/Linux May 06 14:06:26 downloaded from https://rcn-ee.com/rootfs/bb.org/testing/2016-05-01/lxqt-4gb/ May 06 14:07:02 the image : bone-debian-8.4-lxqt-4gb-armhf-2016-05-01-4gb.img.xz May 06 14:07:22 and first, I expected a -bb- image and not a -ti- image May 06 14:07:40 then, its missing all those remoteproc things for the PRUs May 06 14:08:42 root@beaglebone:~# ls /lib/modules/4.4.8-ti-r22/kernel/drivers/remoteproc/ -> omap_remoteproc.ko May 06 14:08:58 ^^thats the output of 'ls' May 06 15:17:36 if anyone can help, I want to use the latest non-ti kernel image with latest pru-related-remoteproc modules. What image should I use ? May 06 15:18:13 ZeekHuge: so that rcn-ee image came with 4.4.8? May 06 15:18:28 yes . May 06 15:18:47 why not just use the 8.3 image from http://beagleboard.org/latest-images ? May 06 15:19:35 if ti isn't done with their latest revision of pru-remoteproc then I don't see much point in trying to use it May 06 15:20:27 that image was build 2016-01-24 isnt it too old ? May 06 15:21:14 what's too old mean? it's the latest official stable release May 06 15:21:47 the images with 4.4.x seem to all still be beta May 06 15:22:05 even if the build date and the release dates here : https://github.com/beagleboard/linux/releases?after=4.1.17-ti-rt-r48 would have matched, we could have then checked what the image actually contains. May 06 15:23:24 oh, well you can always update the kernel with apt-get, the more important thing about the images is what debian version is installed May 06 15:24:18 since they don't use rolling releases May 06 15:34:19 Maybe I don't know the definition of rolling releases all that well but Sid is pretty rolling. May 06 15:39:12 https://en.wikipedia.org/wiki/Rolling_release May 06 15:39:12 [WIKIPEDIA] Rolling release | "In software development, a rolling release or rolling update development model refers to a continually developing software system; this is instead of a standard release development model which uses software versions that must be reinstalled over the previous version. Rolling release development models..." May 06 15:40:30 Sid is never replaced by Sidv2... does that count? May 06 15:41:22 according to the wikipedia entry sid is a cyclically rolling release May 06 15:42:14 Well there we have it. May 06 15:43:57 Pretty sure you can set your apt sources list to "stable" instead of a release name and it rolls like a square. May 06 15:46:39 alexhiam: okay, so regarding the projects, we do not need to worry much about the debian version. Isnt it ? May 06 15:48:59 m_w: ^^ May 06 15:49:39 the version of debian that is actually supported May 06 15:53:45 m_w: ah ?? May 06 15:53:55 didnt get that part .. May 06 15:54:41 https://beagleboard.org/latest-images May 06 15:55:25 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots May 06 16:47:14 m_w: yeah okay, so even if the debian version is old ie the image is old, that wont actually affect the project and its internals. right ? May 06 17:14:13 not entirely May 06 17:14:26 the kernel version is the most important thing May 06 17:36:56 Hi ZeekHuge May 06 18:58:31 hi amragaey .... May 06 18:58:47 just remembered about the web interface.... getting around a silly firewall. May 06 18:59:28 you still around or did I miss you? May 06 18:59:40 * jkridner didn't see you this morning. May 06 18:59:44 hi alexhiam May 06 19:06:58 hi all May 06 19:07:34 hi jkridner May 06 19:07:58 howdy Wormo May 06 19:10:34 hi jkridner May 06 19:11:41 i'm amragaey, jkridner May 06 19:11:59 internet disconnected and name changed :) May 06 19:12:31 hi amr__ ! May 06 19:14:14 I sent you email with updates May 06 19:14:52 different than what I replied? May 06 19:15:52 so, I saw you broke down some BBUI tasks, but I need to to redo your proposal updating with the new schedule and deliverables.... May 06 19:16:02 we should stay 100% aligned on that document. May 06 19:16:20 right now, I think both alexhiam and I have concerns with it. May 06 19:16:48 I checked your reply now May 06 19:17:03 ok, let me know your concerns May 06 19:19:07 I'd like to see the schedule re-written #1.... and we should discuss the architecture of how we will run Python code and what Cloud9 integration, if any, would be. May 06 19:20:48 btw, I've been playing with an old view of the precursors to bone101: http://jadonk.github.io/linux_education/presentations/tops-down/#(1) and http://beagleboard.org/static/presentations/boston2011/beagleboard101/ May 06 19:22:19 Okay so I have finally settled down with the 4.1.18-ti-r55 kernel. The image build is of 2016-03-27 and the driver/remoteproc contents are : omap_remoteproc.ko pru_rproc.ko pruss.ko, ie it contains the "split up" version of remoteproc. May 06 19:22:35 ds2, Wormo , m_w ^^ May 06 19:22:48 Just to bring under your notice ^^ May 06 19:25:33 Ok, let me check it May 06 19:26:50 ZeekHuge: that's good you've got the newer one going May 06 19:27:06 after the split May 06 19:28:48 jkridner, so from slides do precursors important in process operations ? May 06 19:30:30 I want to discuss the python integration, as I can see now the python code will be pushed by javascript, and the server will run this code on board. May 06 19:31:40 amr__: I don't understand the question. May 06 19:32:52 I'm not getting what is the precursors for ? May 06 19:35:17 you have an experience working with file system and system calls May 06 19:35:34 Wormo: yeah. Now trying to get the rproc working here .. May 06 19:36:00 this part would be useful in python integration, we will need to run a python file on bb server May 06 19:38:27 * ZeekHuge is loving this GSoC community. We have formed a fb group and everyone's introducing there and just talking commenting. Its really cool ! Though I am keeping out of fb as it all consumes up lot of time anyway. May 06 19:39:24 amr__: If you are on fb, you should come up there. Only two students from beagleboard.org are up there. Me and chanakya_vc May 06 19:40:38 ZeekHuge, great, let me know group url :) May 06 19:41:24 amr__: what your id on fb ? May 06 19:41:53 *whats May 06 19:42:33 amr__: just some perspective on the history of bone101 May 06 19:42:59 ZeekHuge, PM May 06 19:43:24 jkridner, well I found it useful May 06 19:47:51 jkridner, did you like the python integration approach? May 06 19:48:44 you mean the idea of running "a python file on bb server"? May 06 19:48:56 so, modifying the web server to run python scripts? May 06 19:48:58 yes May 06 19:49:15 it will run on local beaglebone server May 06 19:50:21 it would be simple enough. Note that b.writeTextFile() can write a Python file to /var/lib/cloud9/autorun today to get it to execute, but it would remain there if it was reset without deleting and collecting errors could be a bit of a challenge. May 06 19:51:39 We could create a b.runScript() that took a script as one argument and a callback function as the second. The callback could get objects containing stdout/stderr and error return status messages. May 06 19:52:36 not sure if the integration needs to be tighter than that. May 06 19:53:10 maybe a process Id would need to be returned such that we could do a b.kill() to kill the process. May 06 19:53:18 all very insecure, but hey. May 06 19:55:43 this is good and clear to me. I'm thinking to run python files in docker container and destroying it after running. May 06 19:56:28 this will be more secure May 06 19:56:58 but I have to go with the simple case first to make sure everything working. May 06 20:01:28 jkridner May 06 20:05:05 amr__: that is crazy heavy for such a small platform. May 06 20:05:09 (docker) May 06 20:05:36 at least if not making more of the environment run within a container. May 06 20:05:45 certainly not for every script. May 06 20:06:05 and, if you aren't protecting the hardware, does it really make that much sense to protect the file system? May 06 20:06:07 maybe. May 06 20:07:42 How do i protect the hardware from code ? May 06 20:09:25 I can go to some process isolation, thinking of chroot jail May 06 20:12:12 jkridner, May 06 20:14:21 amr__: sure... but you still have to expose sysfs, proc, dev.... so, again, you can help protect people from touching the file system, but for PyBBIO and BoneScript, they pretty much need to run as root and have full access to hardware unless very intentional protection is done. I think it is OK it is insecure, personally. May 06 20:14:33 it is for rapid prototyping and learning.... May 06 20:14:44 only the first step in building a product... May 06 20:15:05 you'll need to go back and run the scripts natively with appropriate access limitations for a real product. May 06 20:19:14 aha, then pyBBIO will run as Bonescript for now. May 06 20:20:54 k. now we just need to decide function details and if I implement or you. :-) May 06 20:25:50 k, I can implement :D I'll see some examples to follow May 06 20:26:53 will we use writeTextFile(), or creating b.runScript() ? May 06 20:28:29 oh sorry, or creating custom writeTextfile ? May 06 20:30:31 we have then two functions runScript and kill May 06 20:36:52 jkridner, May 06 20:39:02 seems like we should create b.runScript() in the pattern of the other BoneScript functions (last argument is always a callback that returns an object and other such conventions) May 06 20:39:40 I'd also create a b.killScript() and make sure that the first callback message contains a process ID. May 06 20:42:37 ok, where can I start ? May 06 20:46:23 jkridner, are you busy now? we can talk later if you like May 06 20:48:18 I'm busy, but best to get any chatting in we can. May 06 20:50:03 could you be a little more specific, since it sounded like jkridner gave you a place to start (b.runScript() skeleton based on existing functions) May 06 20:53:13 ok May 06 20:54:23 Can I have the branch name you're working on now, jkridner ? May 06 21:04:21 amr__: for bonescript? 0.5.0 May 06 21:04:28 on the jadonk/bonescript tree. May 06 21:08:55 well, i'll update the python integration part in proposal and adding the functions we agreed on. May 06 21:10:50 k... and the schedule. :-) May 06 21:11:20 amr__: let us know the URL for the new official proposal so we can finalize it before the bonding period ends. May 06 21:11:53 k, sure May 06 21:36:57 *nod* **** ENDING LOGGING AT Sat May 07 02:59:58 2016