GSoC 2019 PSF Blogs

Final week

PeterBell10@live.co.uk (peterbell10) — Tue, 27 Aug 2019 01:17:48 +0000

What did you do this week?

With the coding period coming to an end, this week I've wound down coding and focused on writing up my final work submission. This means I've been looking back at the work I've been doing; reading through my old PRs and comparing against my project's original goals.

My original proposal focused solely on adding backend support to scipy.fftpack, yet the scope of my work over the past 3 months was not limited there. The resulting scipy.fft subpackage is a complete rewrite of scipy.fftpack from the ground-up featuring not just the backend system but also an improved interface and the replacement of FFTPACK with pypocketfft under the hood.

My contributions were also not just limited to SciPy; I've also made contributed to pypocketfft, uarray, pyFFTW and cupy. I've really enjoyed getting to collaborate with this range of open source projects and am very pleased with how my work has gone over GSoC. I would thoroughly recommend that any students interested in open source software should consider doing a project themself.

Final weekly check-in #7

abhinandan0659@gmail.com (abhinandan0659) — Mon, 26 Aug 2019 19:30:09 +0000

Hey! Wassup?
Time has passed and it's my final blog for Google Summer of code 2019. Every day was just amazing, I learned a lot, enjoyed a lot, worked a lot. This was really a life-changing experience, I am starting to feel different, look at this world from a different angle and I am myself a-lot different from the time when I started this.
Now, about the work:
What did you do this week?
Well, I finished with the implementation of the documentation page of EOS-Icons. I just created a PR for that. PR link - https://gitlab.com/SUSE-UIUX/eos-icons-landing/merge_requests/22. This documentation page will be published at - https://eos-icons.eosdesignsystem.com/docs.html.
I also finished my final evaluations and created my final work report.
What's coming next?
I also created a new PR for a few adjustments on the EOS-Icons landing page. I am planning to refactor the code and improve responsiveness. So, I am working on that now. Later I will work on a few other things that are still pending, mainly deploying strapi on Heroku.
Did you stuck anywhere?
Not really, this week was just about documentation and most of which was already on the readme, so it wasn't that of a big deal.
So, ya this was all for my Google Summer of code 2019. Well, I won't be updating this blog for my future work because this was just for GSoC period. Maybe you can check me out on other platforms.
Here is my linked-in - https://www.linkedin.com/in/abhinandan-sharma-672299150/
My twitter - https://twitter.com/abhinandan0659
Peace!

Final Blog - A Journey full of learnings

anveshanrx8@gmail.com (funnelferry) — Mon, 26 Aug 2019 18:07:49 +0000

Name : Anveshan Lal

Organisation : Mission Support System (Python Software Foundation)

Mentors : Joern Ungermann, Jens-Uwe Grooß

Project : Updating Geographical Plotting Routines

Project Code : Pull Request referencing project code

Commit log : All the commits comprising the all the progress of project

A detailed report about my GSoC project regarding migration of basemap dependent code to Cartopy.

Dependencies

Aside from the dependencies required to run MSS:

$ conda install cartopy

I would detail the progress by headlining the project in 3 parts

1. Server Side Migration

This address changes in code in respect to files:

mss/mslib/mswms/mpl_hsec.py

mss/mslib/mswms/mpl_hsec_styles.py

Current State

Server side is complete with all the previous functionality retained

Remaining Progress

None

Unresolved Issues

Map produced is almost aligned with client perfectly but it is not 100 %

Relevant Pull-Requests

https://bitbucket.org/wxmetvis/mss/pull-requests/643

https://bitbucket.org/wxmetvis/mss/pull-requests/651

https://bitbucket.org/wxmetvis/mss/pull-requests/653

https://bitbucket.org/wxmetvis/mss/pull-requests/654

2. Client Side Migration

This address changes in code in respect to files:

mss/mslib/msui/mpl_map.py

mss/mslib/msui/mpl_qtwidget.py

mss/mslib/msui/mpl_pathinteractor.py

mss/mslib/msui/topview.py

Current State

User Interface is perfectly functional and all the functionality is retained including the interaction of waypoints and functions related to it.

Remaining Progress

If the time allowed I would have like to exploit Cartopy's native ability to plot Geodetic Circular Paths, instead of the current manual solution.

Unresolved Issues

None

Relevant Pull Requests

https://bitbucket.org/wxmetvis/mss/pull-requests/656

https://bitbucket.org/wxmetvis/mss/pull-requests/671

3. Added Support for EPSG

mss/mslib/msui/mpl_map.py

mss/mslib/utils.py

Current State

All the epsg's previously present and additional EPSG's added are supported by the program. This includes the epsg which were non-functional from Cartopy's in-house function to plot epsg codes directly and all others Cartopy already supports.

Remaining Progress

There exists a large number of EPSGs (in excess of 4300), I couldn't test all of them but did encountered few which are not yet supported by Cartopy like 2985, 2986, 7415. With more testing there ought to be more which are still not supported by Cartopy but a large number of them are.

Relevant Pull Requests

https://bitbucket.org/wxmetvis/mss/pull-requests/684

https://bitbucket.org/wxmetvis/mss/pull-requests/691

Testing

Since the project in large part required me to maintain previous functionality there was not much scope to create new tests, but I did add two tests; One to test for a new function I added and the other test for EPSGs.

Failed Tests:

Pytest shows 2 tests failed although the failed tests seem to relate to a working and manually tested functionality of adding and removing point on waypoint interactor.

Acknowledgement

I would like to thank Joern Ungermann who mentored me throughout summer and actively helped me better the program and code, and also provided valuable feedback frequently. I would also like to express my gratiude towards MSS community including Reimar Bauer, Jens-Uwe Grooß and Shivashish Padhi who have been very welcoming from the start and helped get started and be familiar with MSS despite my serious lack of programming expertise and made my summer experience really great.

Final work submission and future work

yashlamba2000@gmail.com (yashlamba) — Mon, 26 Aug 2019 15:58:47 +0000

As the final week ended, we had to submit a compilation of our work during GSoC. Below are some insights:

What was the original aim?

Adding new machine learning models to DFFML, the proposed models are given below:

Model 1: Ordinary Least Square Regression (OLSR)
Model 2: Logistic Regression
Model 3: k-Nearest Neighbour (kNN)
Model 4: Naive Bayes

Decided modifications during community bonding:

During the community bonding period, the proposed work was modified to achieve optimized result from the summer. The finalized work was:

Adding Linear Regression Model from scratch
Adding Linear Regression and other proposed models using scikit-learn
Adding tests for the added models
Documenting the models

Tasks Completed:

Added Linear Regression model from scratch with tests

Simple Linear Regression model implemented from scratch. This was successfully completed with tests and documentation, and was also releasd on PyPI.
Added scikit models with dynamic support Initially, it was planned to add certain number of models from scikit but as I did it with one model (Multiple Linear Regression with scikit), we decided to extend this and make a base for all scikit models and make other model classes dynamic. This was successful and now adding scikit models to DFFML is as easy as appending the model name to a python dictionary. The tests are complete and the documentation material is ready but we are still figuring out a more understandable way of documenting this before release.

Future Work:

The project was started just before GSoC'19 and it has come a long way since. I plan on contributing significantly to the project after GSoC'19. Few of the planned stuff:

Adding more scikit models
Working on more machine learning libraries and add models
Contruct DFFML Web UI from scratch which was conceptualized during summer and much more.

More detailed report: https://gist.github.com/yashlamba/5e0845a6cd5a1198f166ddedfba78802

Final Weekly Check-in

kjlsudharsana@gmail.com (sudharsana-kjl) — Mon, 26 Aug 2019 14:48:10 +0000

In the final week of coding, I was refining the hadoop source PR.

What did I do this week?

The dockerfile is finally working now. We are able to set up hadoop using dockerfile. Also the connection set up is well established in the application.

What is coming up next?

There are few bug fixes to be done. Also Hadoop feature and MySQL feature are going to be packaged and uploaded in PyPi similar to the models. I will be working on that as well.

Did you get stuck anywhere?

Fixing the hadoop source connection and writing a data into HDFS stream was an issue. My mentor and I had another meeting this week and we fixed it.

Check-in: 13th and final week of GSoC (Aug 19 - Aug 25)

alanis.jcg@gmail.com (JoseAlanis) — Mon, 26 Aug 2019 14:15:16 +0000

1. What did you do this week?

As this was the final week of GSoC, I have written and posted a final report of the project here.
In addition, I made a major overhaul of the project's website. Wich now contains a "gallery of examples" for some of major advancements and tools developed during the GSoC period.
See this PR for a more detailed list of contributions made this week.

2. What is coming up next?

There are a couple of open questions that concern the integration of these tools and analysis techniques to MNE's API.
For instance, we've been using scikit-learn's linear regression module to fit the models. One of the main advantages of this approach consists in having a linear regression "object" as output, increasing the flexibility for manipulation of the linear model results, while leaving MNE's linear regression function untouched (for now). However, we believe that using a machine learning package for linear regression might lead to confusion among users on the long run.
Thus, the next step is to discuss possible ways of integration to MNE-Python. Do we want to modify, simplify, or completely replace MNE's linear regression function to obtain similar output..

I really enjoyed working on this project during the summer and would be glad to continue working on extending the linear regression functionality of MNE-Python after GSoC.

3. Did you get stuck anywhere?

Not really. Although the final week included a lot of thinking about what the most practical API might be for the tools developed during the GSoC period. We want to continue this discussion online (see here) and hopefully be able to fully integrate this advancements in the released version of MNE-Python soon.

Thanks for reading and please feel free to contribute, comment or post further ideas!

Google Summer of Code with Nuitka 7th Weekly Check-in

taofengl@uci.edu (tommyli3318) — Mon, 26 Aug 2019 08:24:13 +0000

1. What did you do this week?

As GSoC is wrapping up, I wrote a summary of my work which can be found here.

In addition, I have finalized my pull requests #495 and #484 which are now ready for merge.

2. What is coming up next?

After GSoC ends, I plan on continuing my contributions to Nuitka and PSF.

3. Did you get stuck anywhere?

I do not remember being stuck anywhere this week :)

Week 13: Weekly Check-In (#7) - Last Check-In

s1041134@stud.sbg.ac.at (DiGyt) — Mon, 26 Aug 2019 08:17:46 +0000

1. What did you do this week?

As described in my previous post, I spent last week doing some smaller corrections on my Pull Requests. The biggest amount of work was dedicated to allowing fast and memory saving computation to the tfr_stockwell function, the last function where I haven't implemented this yet. Principally, most of this went similar to the other functions, i.e. I had to create an alternative function which computes stuff separately for lists of SourceEstimate objects, and is capable of handling input from generator objects. However, the tricky and time consuming part was again to make sure the data fields were completely equal.
Another step last week was to change the examples I created, from one example to three example that cover the diffferent TFR functions and SourceEstimate types which can be processed equally.
Finally I did some smaller commits, correcting some stuff that my reviewers mentioned could be made better.

2. What is coming up next?

Well, as my project is finished now, and all of the important functional stuff has been implemented, I will only spend my time working on review corrections, in order to get everything merged into master.
Concerning the extended plotting that I mentioned over the last blog posts, I will probably do a bigger independent PR, that can enhance plotting functionality and modularity.

3. Did you get stuck anywhere?

Yes. As I already mentioned I first had problems with making the data fields completely equivalent, when implementing a time/memory saving version of tfr_stockwell.
But probably even more annoying (because I didn't expect it) was trying to erase Errors when submitting the freshly made examples. I rewrote the exampels first to a MNE-testing dataset which contained real neurophysiological data. Then, when submitting it, noticed that my version of the testing data was outdated (the respective dataset has been revised for another MNE-Python GSoC project running this summer). So I had to adapt the respective file paths again, which would've been no problem at all, if one of the files that I needed for one of my examples (a trans.fif file) wouldn't have been removed from the dataset. So this resulted in trying various solutions to make things work again, until I finally decided to change the example and make it run on a different dataset, where all needed files were accessible.
So next time I'll be using testing data, I'll definitely will make sure to update my testing data folder first.

So this was the last regular report on my GSoC project, and I hope that you've found it an interesting thing to read. As you might have noticed from reading, I've definitely learned alot of things during the project (probably a consequence of doing a lot of mistakes during the project), but I'm glad that I could really notably enhance my coding skills during this summer.
From now (and after having all the stuff from the project entirely merged), I will still try to stay involved in MNE, so I hope that this won't be the last thing that you'll hear from me.

Finally I want to say thanks to everyone who participated in this Google Summer of Code project with me - from my mentors to all reviewers to the people from the Salzburg Brain Dynamics lab to finally you, the reader of my blog.
Thank's to everyone and have a good time - hopefully profiting from my works on MNE-Python this Google Summer of Code ;).

Cheers!

Dirk

Final Report

sounak.98@gmail.com (sounak98) — Mon, 26 Aug 2019 05:55:35 +0000

Summer Rewind

Let’s rewind to the beginning of this year. We had started working on this application way before GSoC had even started. The goal was to have a working application which PSF will be able to use for this year’s GSoC for the management of their students. In this way, we will be able to make sure that students actually use it and we get a clear idea if the application is serving its purpose. I’m glad the plan worked out, because tons of bugs were reported and we could fix them. We also received valuable feedback from all users.

Schedulers and Builders

Allow me to introduce you to some of the most important modules of our system. Without any doubt the first on the list is our Scheduler, which can perform particular tasks from sending an email to archiving webpages. Well, the most powerful feature of this module is that it can perform those tasks at any particular date and time. Need to remind students that they have not written a blog on time? Not a big deal, Scheduler can do that for you. Now think of this, many students who are not like me publish their blogs on time, so we don’t really need to spam them with emails. Thus we built the module Builder which in turn builds Scheduler on different conditions.

Blogging Platform

We didn’t have to create a blogging platform as we integrated aldryn-newsblog but we had to tweak it a lot to fit into our system. Something that we had to work on was setting up custom permissions for each user so that they only have access to their blogs. We achieved this with the help of django admin which allows us to set add, view, change permissions based on querysets! Sanitizing the artilce contents was another challenge that we faced because aldryn-newsblog uses an editor which injects HTML so that users can customize their blog posts. Our system currently allows only particular tags like

, etc. Other tags are sanitized conditionally, like for iframes we only render iframes for YouTube videos so that users can add YouTube videos to their articles.

We also tweaked the article list templates to include our own reddit-styled comment system which makes use of recursion on django templates to display different threads. For more information on how to achieve this, check out the article Creating Reddit Styled Comment System with Django .

Tweaking Django

We used django-forms wherever we could, but there were cases where we needed to customize the forms to an extent which wasn’t supported out of the box. We have a form which lets suborg admins and admins add selected students to the system. Generally, this includes adding a lot of students (~50). Typing out the emails one by one is still okay, but selecting the GSoC year or the Suborg one by one for each student? Ask my mentor, and he will let you know what a pain it is. So, we tweaked the django form to add buttons which would let the admin select a particular Suborg, year for all the mentioned users.

We have RSS feeds for each blog separately (all the articles published by a student) and also for all the articles published on this platform. Django has Syndication Feed Framework which allows customizable RSS feeds, but the all articles feed was too long and took seconds to load. We needed to paginate the feed, and we were out of luck as django didn’t support this out of the box. This was a challenge, as we had to take in the request object and parse the url to get the page number and render the blogs accordingly. We also added the year argument which takes in the year and displays the blogs of that particular GSoC. The current feed url looks something like this https://blogs.python-gsoc.org/en/feed/?y=2019&p=2.

For most of the other admin features, we heavily relied upon django admin. The admin portal lets admins

Add new Schedulers and Builders
Check blog post histories of different articles to track changes
Add the current GSoC timeline which gets pushed to the schedule page in the github site repository
Send custom emails to users as admins
Review comments and delete them if necessary
Disable a user profile if the student fails mid-way

Integration with Github

We annotated some of the manual work that an admin has to put in to maintain the static site on Github. Our system creates pull requests adding new Suborgs in the Ideas page whenever a new Suborg Application is added, it also archives current pages when the GSoC program ends. These pulls can then be reviewed and merged to master by the admin.

Fixing Bugs

This was really a major part of the whole summer and it went hand in hand with the whole developmene process. There were bugs that were found by the users, and the others figured out by the mentors and me. There are a ton of “Bugfix” PRs which were basically bug fixes.

There was a time when we pushed some changes and it made the system send emails to all the users regardless of whether they have blogged or not. Yes, basically we spammed a lot of users unintentionally. This was another challenge that we had faced and overcame eventually by making a flag which would disable all notifications to any user. We also followed a strict push cycle to avoid any disturbance to students blogging at the end of the week.

Wrapping Up

We ran accessibility tests on our websites and fixed issues which decrease the accessibility of the website, like fixing contrast ratios of texts and background, adding alts to images, etc. We also worked on boosting the loading speed of out website on mobiles. In built tools provided by Chrome and Firefox gave us a list of issues after analyzing the website which we could work on.

We also ended up using a cache server to cache the data to fasten up the whole loading process. We also needed to manually override caching in some pages like the comments page, which would not show the new comment as the old one was cached. This is the issue which describes more about this bug and how we solved it.

Future Plans

Currently, the platform provides most of the functionality required for a smooth GSoC run at PSF, but there are features that would make it even smoother for the admins and make their lives a bit less painful. One of them is adding the mentors to the GSoC site automatically from the system’s database. This can be another nasty manual work (typing in the emails, names, etc. one by one) and needs to be done automatically. For more details, check this issue out.

We also need to write unit and integration tests for features that are not provided by django or any third-party packages.

I would love to work on these in future even when this GSoC ends, fix more bugs as and when they come up and be a part of this great community!

Credits

First of all, any of this would not have been possible without my mentors and other members of the PSF community. So a huge shout-out to them for helping me whenever I needed and for guiding me when I was clueless on how to proceed. While I was busy coding, my mentor would look for potential bugs in the system and point them out to me. This really kept me busy throughout the summer as I always had bugs to fix, and helped me make the system more stable.

Next, I would thank Google for organising such an amazing program for students who are passionate about coding and giving them an opportunity to gain some hands-on experience.

Last but not the least, I would thank my fellow applicants who also worked on building the application with me to bring it to a stage where it could be used in this year’s GSoC run.

Apologies

There are a lot of mistakes that I made and learnt from them. In the beginning I was not testing stuff through before making a PR, sometimes trying to do things faster and the other times just being lazy. It only made me spend more time on a particular feature as there were things that would not work.

Another thing that I should apologize for is being very irregular about posting blogs. This shouldn’t have come from me, as I was the student working on the very blogging platform itself.

Weekly Check-In #10

sounak.98@gmail.com (sounak98) — Mon, 26 Aug 2019 05:53:48 +0000

What did I do in these two weeks?

There were a lot of bugs posted, kind of like the last set of major fixes that we need to make.

be able to add gsoc_year
add username to password reset email
prepopulate have you partisipated before
'Settings' object has no attribute 'ADMIN_EMAIL' on suborg form since we removed that key
github username for org admins/mentors
add additional org admins as part of suborg form
cut out top part of suborg form
make a pr on suborg submit, dont auto commit
cookie notice
add mentors/suborg admins button
add psf privacy policy
checkbox on signing up for PSF terms and another for "opt-in to receive emails"
nuke all student users unless they click a link in an email, ie remove email name etc then readd with get request if they click at end of gsoc (gdpr)

In this week we mostly worked on all of these. Terri posted some issues with the comment notification emails that we had totally overlooked. I fixed those too. We also worked on fixing the existing feed and adding blog wise feeds for every blog.

What's next?

Publishing the final report and making some final changes to improve the accessibility of the site, like fixing the contrast ratios, etc.

Paginate Django Feeds

sounak.98@gmail.com (sounak98) — Mon, 26 Aug 2019 05:48:21 +0000

Django has a great framework for generating feeds, but sadly it doesn't support pagination out of the box. Currently we have tons of blogs and the feeds page was loading especially slow with all the pages in it. I was hoping django will have some class variable to enable pagination but I was out of luck. But it had a method which took in the request, so I knew I had to parse the page number from there.

from django.contrib.syndication.views import Feed

class BlogsFeed(Feed):
    ...
    def get_objects(self, request):
        ...
        page = request.GET.get("p", 1)
        ...
        return queryset_from_page

So in the get_objects method we need to get the page number from the GET args and then return the queryset according to the page number.

That seems to be enought right? Even I thought so. But the RSS standards say that we also need to add entries like url for last page number, first page number and the current page number. Well, we can even do that. The class BlogsFeed takes in a class variable called feed_type and we need to set it to the feed type class and django provides a class for that too called DefaultFeed. Well we will inherit this DefaultFeed and make out own type of Feed which will include the page numbers too.

from django.utils.feedgenerator import DefaultFeed

class PaginateFeed(DefaultFeed):
    content_type = "application/xml; charset=utf-8"

    def add_root_elements(self, handler):
        super(CorrectMimeTypeFeed, self).add_root_elements(handler)
        if self.feed["page"] is not None:
            if not self.feed["show_all_articles"]:
                if (
                    self.feed["page"] >= 1
                    and self.feed["page"] <= self.feed["last_page"]
                ):
                    handler.addQuickElement(
                        "link",
                        "",
                        {
                            "rel": "first",
                            "href": f"{self.feed['feed_url']}?y={self.feed['year']}&p=1",
                        },
                    )
                    handler.addQuickElement(
                        "link",
                        "",
                        {
                            "rel": "last",
                            "href": (
                                f"{self.feed['feed_url']}?y={self.feed['year']}"
                                f"&p={self.feed['last_page']}"
                            ),
                        },
                    )
                    if self.feed["page"] > 1:
                        handler.addQuickElement(
                            "link",
                            "",
                            {
                                "rel": "previous",
                                "href": (
                                    f"{self.feed['feed_url']}?y={self.feed['year']}"
                                    f"&p={self.feed['page'] - 1}"
                                ),
                            },
                        )
                    if self.feed["page"] < self.feed["last_page"]:
                        handler.addQuickElement(
                            "link",
                            "",
                            {
                                "rel": "next",
                                "href": (
                                    f"{self.feed['feed_url']}?y={self.feed['year']}"
                                    f"&p={self.feed['page'] + 1}"
                                ),
                            },
                        )

This code pretty much explains itself. But there is one catch here too self.feed dict does not have a 'page' or a 'year' key. We need to pass that from our BlogsFeed class. Let's see how.

class BlogsFeed(Feed):
    ...
    feed_type = CorrectMimeTypeFeed
    ...
    def feed_extra_kwargs(self, obj):
        return {
            "page": self.page,
            "last_page": self.last_page,
            "show_all_articles": self.show_all_articles,
            "year": self.year,
        }

That's it guys. Now you have your own paginated feed as per the RSS standards.

Weekly Check-In #9

sounak.98@gmail.com (sounak98) — Mon, 26 Aug 2019 05:02:52 +0000

What did I do this week?

We have come to the last phase of the summer. The application is almost ready but we needed to fix more bugs this time to fine tune the application. Some of those which we worked on this week were as follows.

Fixed the sitemap to include each blog post and also different pages for the paginated blog
Handling exceptions on sitemap
Use django for sending mails to admins when any exception is raised on the main server
Fixed a very very old issue by enhancing the user add feature. Now the admin can use single dropdowns to select the default values for multiple fields.

What will I do next week?

Will move towards finishing up whatever is left and work on more issues as and when they come up!

That will be all folks!

Week 11-12 Check-In

hec@bxscience.edu (hecris) — Mon, 26 Aug 2019 03:33:15 +0000

I am happy to announce that `CollisionHeightfield` is near completion! This week, I added some finalizations to `CollisionHeightfield`, which included improving the collision tests and adding the getter/setters of the class. My next steps would be to push my unit tests to the PR, and provide sample code which demonstrates the new CollisionSolid in action. One goal that I did not get to accomplish was to implement BAM serialization for `CollisionHeightfield`. BAM is one of Panda3D's native file formats, allowing users to export Panda3D objects. Additionally, I did not add collision tests for lines and line segments. `CollisionHeightfield` currently has a collision test for rays, which is probably used more commonly than line/segments in regards to terrain. However, it would be nice to add these tests, especially since they are only slight variants of the ray collision test. Regardless, I am happy to announce that `CollisionHeightfield` is pretty functional as is. That is all for this week, check back next week for my final blog post!

Panda3D iOS Support - A Postmortem

treamology@gmail.com (treamous) — Mon, 26 Aug 2019 00:00:47 +0000

Hi everyone!

Well, it appears that this is the end of the line when it comes to my GSoC portion of my work. I got a huge amount of work done and am extremely proud of it, and I can't wait to continue working on this project in the coming months and make it the best it can be. This blog post is here to detail the work I completed over the summer, and also what I didn't have time to get to. So, let's begin!

Everything I completed

CMake Build Support

This actually ended up taking a lot of my time this summer (around a month). Currently, Panda3D uses a custom build system known as makepanda. Although this is a venerable and versatile build script, it was decided that a more standardized build system would be a better choice, so work began on replicating our current system with CMake. Because I began my iOS work before the CMake system was actually complete, this led to a couple of instances where I wasn't sure if there was an issue with my own code or with the Panda's experimental CMake implementation. In the end, however, thanks to CMake 3.14's new support for iOS devices, I was able to complete this task within the expected time frame.

eagldisplay

David Rose, who briefly worked on an iOS port (back when iOS was iPhoneOS), created the iphonedisplay module as an experimental method of running Panda apps. While this was a good starting point, I felt it was best to start from scratch considering the number of changes iOS has seen since the days of the iPhone 3G. This new display module should be easier to extend in the future when adding in a Metal backend, for example. Most of this is complete - there is support both for GraphicsWindows and GraphicsBuffers, along with some basic features such as autorotation.

PandaViewController

PandaViewController is a helper UIView that encapsulates the entirety of Panda on the Cocoa side of things. All one needs to do is specify where the Python source is, and PandaViewController will handle initializing Python and handing control to the Python script. I decided to go with this method of starting Panda mostly so existing apps can easily integrate Panda - it doesn't take over the main application loop or anything, so it quite very nicely with existing systems.

make_xcodeproj and makewheel.py

In addition to actually getting iOS support working, I also wanted to get started on the deployment process. Firstly, this required modifying makewheel.py to allow for the creation of wheels for iOS. This actually ended up being more complicated than I was first expecting, since makewheel had been designed to only generate wheels for the host system. I got it working in the end, though, and was able to begin churning out iOS-specific wheels. In addition, I had to add a new command to our setuptools-based deployment system that allows for the creation of Xcode projects, since that is the only way to test and deploy iOS apps on-device.

Multitouch (only partially)

I had gotten mouse emulation working well pretty early on in the project, since it was just a matter of converting touch events to the existing mouse events Panda is used to. Adding full-blown multitouch, however, has been much more of a challenge. Panda is not accustomed to handling multiple pointers (or anything other than a mouse, for that matter), so it took some changing at the architectural level, but I got a partial implementation working.

Stuff I didn't get to

DirectGUI touch support

This is something that I simply didn't have time for. It took me longer than expected to change Panda's architecture to allow for multiple pointers. While the DirectGUI widgets will indeed work, any touch specific gestures such as swiping to scroll are not present.

C++ app support

I had decided to prioritize getting Python working over C++, since the vast majority of Panda apps are written in Python. This should not be too difficult to accomplish; it should just be a matter of changing the entrypoint that PandaViewController uses when spawning a new thread.

Custom file handler for make_xcodeproj

Currently, make_xcodeproj just does a straight copy of all the game files, and ignores the custom handlers that can be specified in build_apps.

Documentation

Although I documented a lot of the code through comments, I failed to write any manual entries or longform docstrings. When I do this in the future, I would like to wait until we are filly migrated to the Sphinx manual instead of our custom MediaWiki stack.

Unit Tests

I never got to these simply because it would have taken a while to figure out what to actually test. As far as I know, there also isn't any good method of running tests on the C++ side of things; most of the existing unit tests utilize the generated Python bindings and call into the codebase from there.

What I could have done differently

Better communication with mentors

I did not talk to and consult with my mentors over Discord as much as I should have. I have a habit where I am hesitant to get feedback on my work unless it is in a somewhat completed state; I would end up telling myself, "I just need to finish up this one last feature/bug/whatever, then I'll push my work." And before I knew it, a week had passed by! This led to me dumping large changes all at once, which certainly was not helpful in quickly getting feedback.

Separation and organization of my work

I mainly used two branches for development: one called "cmake-ios" that I used to add CMake support and also write the display backend, and then a separate "multitouch" branch that is based from "cmake-ios". For my GitHub pull request, I ended up just merging everything into an "ios" branch, so a lot of different types of commit are all intertwined. There's not a lot of separation where someone can think to themselves, "oh, they added this feature in this commit, then continued working on it in this next commit". It's more like a developer with ADHD jumping around between features and bugs whenever they get noticed.

Although this is the end of my GSoC experience for this year, it is not the end of my work with Panda. I had already fixed a few bugs and gotten a few pull requests merged before I started this project, and I don't plan to stop that trend. Additionally, I am excited to continue my work on the iOS backend into the fall (on my own time, without a deadline looming over my head!). I am extremely happy with how everything has turned out so far, and am super excited to continue working with my mentors and everyone else in the community!

So long!

[Blog #6] Part of the journey is the end.

anubhavp28@gmail.com (anubhavp) — Sun, 25 Aug 2019 20:07:38 +0000

Part of the journey is the end. It is time for me to work on my final work report for final evaluation of Google Summer of Code 2019. This week, I will devote my time mainly to write my final report and final blog post. If time permits, I will work on my PRs from last week.

Last week, I worked on getting Travis to push automatically to PyPI and I redid benchmarking.