GSoC 2013, an afterword

The Summer of Code 2013 is over, and here is what I have to say about it.

Introduction

The project is live at http://paste.hskll.org. The source code can be found at http://github.com/co-dan/interactive-diagrams.

I would like to say that I do plan to continue working on the project (and on adjacent projects as well if possible).

Interactive diagrams

Interactive diagrams is a pastebin and a set of libraries used for dynamically compiling, interpreting and rendering the results of user inputted code in a secure environment.

The user inputs some code and the app compiles and renders it. Graphical output alongside with code can be useful for sharing the experiments, teaching beginners an so on. If the users inputs a code that can not be rendered on the server (i.e.: a function), the app produces an HTML5/JS widget that runs the corresponding code.

The produced libraries can be used in 3rd party services/programs.

Screenshot

Screenshot

Technology used

The pastebin is powered by Scotty and scotty-hastache, the access to PosgreSQL db is done via the excellent persistent library. The compilation is done using GHC and GHCJS inside the workers processes powered by the restricted-workers library.

You can read some my previous report on this project which is still pretty relevant.

I plan on updating the documents on the wiki sometime soon.

Progress

The bad news is that I don’t think I was able to 100% complete what I originally envisioned. The good news is that I seem to know, almost exactly, what do I want to improve and how to do that. As I’ve mentioned I plan on continuing with the project and I hope that the project will grow and improve.

One thing that I felt was annoying is the (technical) requirement to use GHC HEAD. Because of that a lot of packages required updates and fixes. Due to changes in GHC and bugfixes in GHCJS I had to perform the tiring and not so productive procedure of updating all the necessary tools, rebuilding everything and so on. But I guess that’s just how computers work and I am sure that in the future (with the release of GHC 7.8 and a new Haskell Platform) the maintenance and installation will be much easier. Another thing that took a lot of my time was configuring the system and setting up the necessary security measures, which was also necessary.

Other stuff that kinda slowed thing down include: the lack of a good build system, in some cases non-American timezone (actually I think that the fact that my mentor, Luite Stegeman, was quite close to me in terms of timezones allowed us to communicated very frequently, as we did), the lack of knowledge of the tools I used (although you can think of it this way: I had an ability to learn exciting new things ;] ).

Among the grand things I plan to do: release a library for manipulating Haskell AST at the GHC level; make an IRC bot using the eval-api and restricted-workers; continue writing my notes/tutorials about GHC API (I have a few drafts laying around).

Some code refactoring should come along and a number of features for the pastebin should be implemented.

Feelings

When the end of the program was approaching I predicted that I would have that sort of conflicted feelings that you usually get when you finish reading a good book – one part of you feels happy because you had an enjoyable experience, yet another part of you doesn’t feel so giddy, because the thing that you enjoyed is over. Well, I didn’t get this with GSoC. I did feel happy, but I didn’t get this touch of sadness. GSoC was a way for me to get into collaborating with people on real-world open source projects, and the end of GSoC for me is a beginning of something else. I can use my experience now to write better code, write more code and write useful code.

Concluding

I had a very exciting summer and I would positively recommend anyone eligible to participate in the Google Summer of Code program. There is, however, a thing to remember. Programmers are known to be the kind of people who set ambitious goals. Reach for something inspiring, ambitious, yet realistic. Make sure to find something in between, that way you’ll have a concrete target that you know that you are able to achieve, but you also have a room for improvement.

PS. Acknowledgments

I would like to thank various people who helped me along the summer: Luite Stegeman, Brent Yorgey, Carter Schonwald, Daniel Bergey, Andrew Farmer; everyone in #diagrams, everyone in the #haskell channel who patiently answered my question; everyone on GitHub who responded to my comments, questions and pull requests. The Haskell community is lucky to have a huge amount of friendly and smart people.

About these ads

7 thoughts on “GSoC 2013, an afterword

      • Ack, I hope that wasn’t my fault. Any idea why it bailed out? Feel free to contact me by email (afarmer at ittc dot ku .edu) if I can help.

        One small thing: I notice you’re using logStdoutDev instead of logStdout. The Dev version will flush the handle on every write, which is not great performance-wise (but useful for development, obvs).

    • I think the main problem was having to work with GHC HEAD, with some changes to support GHCJS (patches have been merged now, so people using GHC 7.8 should be good for installing GHCJS from hackage when it’s released), which required quite a bit of upkeep due to everything changing all the time, for example primops keep changing (Bool -> Int# change multiple times, TH changes for roles and other things). On the other hand, basing the project on a GHCJS modified to work with older GHC would mean that we would have far less experience with the GHC modifications required, so the patches would probably have been of lower quality, or simply not ready on time. In the end I’m quite happy with how it turned out, and I’m sure

      The GHCJS boot system (that builds ghc-prim, integer-gmp, base, ghcjs-prim, ghcjs-base and some more things) used to hook into the GHC build system, and required a configured GHC source tree. Now parallel building for GHC has been merged (-j flag) and GHCJS can use this through the hooks patch that got merged last week, building the base libs with cabal-install has become a lot faster, and I’ve changed the boot program to use that instead, so it can just build the packages now, without a GHC source tree. It is, however, still quite a bit slower than the GHC make system.

      Do you think it would be possible to use Shake to improve this? It would be particularly awesome if we could run a few examples from the GHCJS testsuite after a change in the code generator, and it would only recompile the modules in base, integer-gmp etc that the tests depend on.

      • In general, if it’s a dependency problem, Shake can solve it – nothing you’ve described seems that difficult. However, it is probably a fair amount of engineering, specifying dependencies and plumbing everything through, and you might still require a GHC source tree to stop GHC putting everything into packages too soon. Ideally GHC would switch to a Shake based build system, which then would be in Haskell and thus trivially reusable in a Shake based build system for GHCJS.

        If you have any specific “how would I do that” questions feel free to mail the Shake mailing list: https://groups.google.com/forum/?fromgroups#!forum/shake-build-system

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s