ABCDEFGHIJKLMNOPQRST
1

What the student will be working onWhat deliverables is the student working towards achieving?Do they have to know Haxe? Ocaml? C++? In depth knowledge of one of the targets? General web knowledge? etcWhat will the student learn about open source software development, and being involved in complex software projects, thanks to doing this project?
2
Project NameMentorsBrief ExplanationExpected ResultsKnowledge Pre-requisitesExpected Learning
3
Haxelib EcosystemJason O'Neil
Juraj Kirchheim
Nicolas Cannasse		Improve the Haxelib tools to support a more vibrant ecosystem.

This includes:

* easier submission of projects,
* better dependency handling,
* automatic documentation generation for the website,
* automated unit testing before submitting etc.		1. Modifying "haxelib submit" to be able to submit the current directory, without requiring you to zip/package the contents yourself.

2. Allowing fuzzy dependency matching using SemVer. All libraries use a SemVer version, but currently only exact version matching is supported. Dependencies on "2.*" for example should get the latest compatible version of the 2.x series.

3. Develop and document tools for generating ".xml" files describing your API, and then include those tools on the website, where they are used to generate API documentation.
Haxe. (Both the Haxelib website and command line tool are written in Haxe).

Understanding of web basics (HTML, CSS, HTTP requests etc)

(Desirable) Experience with other package managers: Bundler, NPM etc.
* Increase knowledge of Haxe build process
* Exposure to other ecosystems and their dependency management processes
* Experience working with various stakeholders (many different uses for haxelib)
* Be part of developing a tool that every single Haxe developer uses

4
Automated Build InfrastructureCauê Waneck
Nicolas Cannasse
Jason O'Neil		Set up the necessary infrastructure for Haxe to automatically build binaries for all supported platforms based on Github commits. Make downloads available, show unit test results from Travis, etc. This would make releasing small bug-fix versions much easier.1. Ability for Github commits or pull requests to trigger a build system hosted on Amazon S3 or similar.

2. Builds for all major platforms (Mac, Windows, Linux) in both 32 bit and 64 bit variants, with appropriate install packaging.

3. Automatically uploading new downloads to a cloud storage provider (Cloudfront or similar) and linking onto Haxe website.		Comfortable with command line interfaces, compiling software etc.

Comfortable with GIT or similar version control technologies.

(Desirable) Experience with automatic build systems.

(Desirable) Experience with cloud providers such as Amazon Web Services (AWS).		* Experience working with cross-platform build systems.
* Increased familiarity with Haxe development process.
* Experience with software packaging options for different operating systems. (eg apt-get, homebrew, self installing executables)
5
Client Side JS FrameworkJason O'Neil
Sam Macpherson (?)		Haxe can compile to Javascript for developing rich web-based applications, and while it can use "externs" to load existing libraries, complex frameworks such as "Ember" or "AngularJS" have quite specific coding styles which feel quite foreign in Haxe and do not take advantage of features such as compile-time type safety, macro pre-processing, or compiling to multiple platforms.

This project would involve extending an existing Haxe library (or creating a new Haxe library) that has templating and data-binding features similar to libraries such as Angular, but taking full advantage of Haxe. Existing libraries such as detox (Jason O'Neil) or haxe-dom could be used as a base, and a number of reactive libraries could also be of interest (thx-react, tink-reactive, etc)		1. Create a comparison of existing Haxe frameworks and libraries with the popular frontend-javascript frameworks (Backbone, Angular, Ember etc).

2. Decide which library to focus on improving, or if there exists a compelling reason to start a new library, articulate why this is so. Discuss which missing features are the most important to implement.

3. Contribute code to the libraries, adding missing features etc. All code should be well documented.

4. Develop a blog post or tutorial demonstrating the new framework, and showcasing advantages of using this over existing JS technologies.		Strong knowledge of Javascript and the Browser DOM.

Existing experience with Haxe, even if limited.

(Desirable) Experience with existing JS reactive frameworks such as Ember and Angular.

* The student will gain a strong understanding of the current reactive frameworks in the javascript ecosystem.
* The student will gain insights into the framework design implications when using a strongly typed language such as Haxe, as compared to a weakly typed language such as Javascript.
* The student will work heavily with the Javascript and the DOM, skills which will be transferable outside the Haxe community.
* The student will be exposed to Haxe macros, and their usefulness in providing extra safety and features to compiled code.
6
Improvements to HScriptHeinz Hölzer
Jason O'Neil
Nicolas Cannasse (?)		Hscript is a library for Haxe that lets you parse and execute scripts, written with Haxe syntax, at runtime. It is of particular interest as it lets you update specific pieces of code (eg game logic) at runtime, without requiring a software update or restart. Many developers are interested in this as it gives them confidence they can provide updates to mobile applications without waiting for updates through the app stores to be approved.

Having said all this, Hscript was orginally written during the Haxe 2 release cycle, and though it has been ported to Haxe 3, new syntax and features in Haxe 3 have not been added to hscript.

There is also room for speed improvements and other features. See also https://github.com/sanghuacai/hx-inter		1. Inclusion of new syntax and structures in hscript.

2. An analysis of hscript speed, and comparison to other runtime scripting options. Identifying key bottlenecks, and explore strategies for improving speed.

3. Based on what is discovered in (2), implement changes to help improve speed and flexibility of Hscript.		Existing experience programming in Haxe.

Ability to deploy Haxe code to multiple targets in order to test performance (eg different browsers, neko, C++, Java etc)

(Desirable) Working with ASTs (Abstract Syntax Trees)

(Desirable) Working with Profilers and other tools to analyze code performance and bottlenecks		* Working with ASTs, which is good experience for being involved in programming language development.
* Strategies for profiling code to optimise performance when dealing with many different target platforms.
7
IDE Support FrameworkHeinz Hölzer
Simon Krajewski (?)		The Haxe compiler currently provides built in support for code completion, to make it easy for IDEs to implement.

This project would provide similar tooling for more advanced IDE features, with a special interest in features that help with refactoring. (Compiler assisted "Jump to declaration", "Find all references" etc).

The end result of this project would benefit not just a single IDE, but rather, allow any IDE to add extra features for Haxe refactoring.
A tool, either integrated into the compiler (written in OCaml), or run as a haxelib (written in Haxe) that can help provide useful information for IDEs.

The tool would interface with IDEs either through a command line interface, or using the Haxe Remoting protocol.

At least one new IDE feature must be supported by the tool (eg. compiler assisted "jump to declaration").

A reference implementation would be required in one of the popular IDEs (FlashDevelop, Sublime Text, IDEA), as well as documentation on how the features could be added to a different IDE.		Strong understanding of the Haxe language.

Experience with existing IDEs with features similar to those we seek to implement.

If the approach chosen involves direct interaction with the compiler, a working knowledge of OCaml, will be required.
* Developing tooling useful to developers, and working with IDE language plugins specifically.
* Developing either a command line interface or a protocol for having the compiler interact with the IDE in a way that can be implemented by different software products.
* Working with ASTs (Abstract Syntax Trees), and being able to draw useful information from them.
8
Interactive Haxe Shell (REPL)Jason O'Neil
Simon Krajewski
Ian Martins		The Haxe toolkit does not currently come with a REPL (Read Eval Print Loop, an interactive shell for the language), but these are helpful for learning a language, experimenting, and debugging.

Currently there is a library "ihx" which provides a REPL, but it is limited, especially in regards to Network, IO, Database access etc. The reason is that it takes the commands entered, compiles them, and executes them with every new command you enter, so any commands which have side-effects on the system (such as creating a new file) are repeated more than once.

A restructure of this project, or a new project, would be an interesting task for a student and a valuable tool for the Haxe community.

Possible approaches:

* Figure out a way to deal with APIs with side-effects, network etc.
* Look into compiling neko modules, and dynamically loading them, so the program holding the current state stays open.
* Investigate if an OCAML implementation in the compiler itself is feasible.		To begin with, an evaluation of the existing solutions, as well as a comparison with REPLs in other popular languages, would be most helpful.

Based on this, decisions as to which project to extend, and which features to implement will be made. By the end of this project, there will be a working REPL tool for Haxe with minimal limitations, and very predictable behaviour.

Key features that could be implemented on top of the existing feature-set of IHX:

* Ability to work with APIs that have side effects, for example, opening a file and writing to it.
* Intelligent printing of values, deal with recursion, indentation etc.
* Tab based code completion, based on suggestions from the compiler
* Colour display of data in the CLI application.

If well polished enough, this could be included in the Haxe core toolkit as a key part of the Haxe workflow.		Existing experience programming in Haxe.

Existing experience creating Command Line Interface (CLI) applications.

(Desirable) Existing knowledge of the neko platform and tools used for dynamic code loading.		* A deeper understanding of the Haxe compilation process.
* Exposure to low-level neko code that can be used to load libraries dynamically.
* A look at which APIs in Haxe are safe to use "without side effects", and exploration of ways to handle resources such as File Handles between multiple command entries.
* Creation of a tool that will be used by many in the Haxe community.
9
Improvements to Basis FrameworkAaron Spjut (developer)
Cauê Waneck (java target developer)
The Basis framework provides a way of using Haxe to create native UI apps for both iOS (Using a CFFI bridge between Haxe C++ and ObjC) as well as Andoird (Using Haxe Java).

A student could help create classes which cross-compile to both iOS and Android for things such as simple list views, table views, menus etc. Key UI components used in both operating systems could be identified, and a unified interface for interacting with them developed in Haxe. This would still use the Native UI on each platform.

Work could also be done to look at using either "haxeui" or "stablexui", which draw their own UI components, as a fallback for other minority platforms.
1. An analysis of the existing Basis library, and an overview of the various UI classes most commonly used in simple mobile applications across both platforms.

2. A comparison of the APIs for Android and iOS, and suggestions on ways these can be managed with a unified API while maintaining their native look.

3. A haxelib library that uses Basis to provide a unified set of UI classes across both Android and iOS.		Existing experience developing for iOS or Android.

Existing experience programming in Haxe.

Desirable: experience with using a CFFI bridge between C++ and ObjC		* Interfacing between Haxe code and native code.
* A thorough understanding of the key similarities and differences in the UI between the two systems.
10
A Unified Http Request / Response API across platformsJason O'Neil
Cauê Waneck (for Java)
Juraj Kirchheim (for Node/PHP)		Haxe has a core API that works consistently across all target platforms, and covers classes such as String, Map, Array and EReg. 3rd party libraries can provide a consistent cross platform API for other functionality, as OpenFL does providing a flash-compatible graphics API on non-flash targets.

This project would involve creating a consistent "HttpRequest" and "HttpResponse" class that behaves similarly across all platforms: NodeJS, PHP, Neko, Java (Google App Engine etc), C# (Azure etc), Client JS (using the Browser History API).

The "ufront" haxelib currently has these classes available for PHP and Neko (Client JS is in development), and these may make a useful starting point, though it is not required.		1. An analysis of how Request and Response classes are handled in popular frameworks (MVC, Spring, django, rails), with benefits and disadvantages of each approach.

2. Develop a consistent API / Interface for the HttpResponse and HttpRequest classes. Ensure these are well documented.

3. Develop implementations for each desired platform (to be decided by student).

4. Devise an appropriate way to test these to ensure cross platform consistency.
Experience programming in Haxe.

An understanding of basic web architecture, HTTP Requests etc.

Desirable: experience with existing web frameworks and a knowledge of their implementations.

Desirable: knowledge of a number of web platforms (eg. PHP and NodeJS) so that implementations of the HttpRequest and HttpResponse classes can be made.		* Developing APIs that can function consistently across different environments.
* Using Haxe's type system to select the appropriate implementation of an API depending on the target and deployment context.
* Accessing low level functionality on several different platforms and using it to provide a consistent high-level API.
11
Improvements to try.haxe.orgClement
Jason O'Neil		try.haxe.org is a tool that people can use to experiment with Haxe for the first time, or to show a small code sample to people online. It is similar to JS Fiddle, but is able to compile Haxe code into either Javascript or Flash.

There are a number of improvements that could be made:

* support multiple files in the compilation process
* support HTML/CSS
* support custom graphics assets
* support macros (need to sandbox properly)
* support compiling to neko (need to sandbox properly)
* easy embedding for blogs / wiki usage		The student would work with the mentor to choose a number of key features to focus on for their project.

Each of these would be delivered and well tested in multiple browsers, to ensure it functions correctly.

If the project progresses smoothly, try.haxe.org would be updated to incorporate the changes.

Please note that the source code for try.haxe.org is open source and available for everyone.		Experience programming in Haxe.

Experience working with HTML, CSS.

Desirable: knowledge of web server security and sand boxing.

Desirable: experience with online code editors such as CodeMirror or ACE.

Bonus: experience compiling the Haxe compiler, especially with custom configurations.		* Strategies for deploying a complex Haxe website.
* Knowledge of security requirements when executing code on public servers.
* Experience creating custom versions of the Haxe compiler or Standard Library that are stripped of unsafe features.
12
An Asynchronous abstraction of Haxe's DB Records APIJason O'Neil
Nicolas Cannasse (?)
Haxe has a very powerful API for Object Relational Management (ORM) of databases, that uses macros so you can write Haxe code and it is translated into safe, sanitised, type-checked SQL statements.

Currently, this code only works on a synchronous connection. This project would look at abstracting the key macros used in this API so that they can be re-used on a platform with asynchronous database access, such as NodeJS.

For extra credit, if the abstraction could be made to work so database actions could be triggered from the client in a way that still prevented SQL injections by allowing some kind of prepared statements. An existing tool for managing database records from the client exists in ufront-orm, but this does not have the powerful syntax of the Haxe DB Records API.		The existing code in sys/db/RecordMacros.hx would be abstracted so that it is no longer tightly coupled with the synchronous sys.db.Connection class. The macros could still generate the appropriate SQL statements, but they could now be delivered to an asynchronous connection.

Set up sys.db.AsyncConnection class could be created, with reference implementations for NodeJS.

Make changes to sys.db.Object as required to get the code to work on async platforms - for example, save() could either take a callback or return a future.

Experience working with Haxe.

Knowledge of SQL databases and ORMs generally.

Desirable: experience with both sync platforms (PHP, Neko, Python) and Async (NodeJS)

Desirable: experience with Haxe macros.
* Advanced use of Haxe macros to create powerful, safe and expressive APIs.
* Experience creating code that can be shared across very different (sync vs async) environments.

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98