Your first VOC contribution

The new version of wiki is moved here

---

So you want to contribute to an Open Source project, but you don't know how? No problem - VOC is a great place to start.

Imposter syndrome

There may be a little voice inside your head that is telling you that you're not ready; that you need to do one more tutorial; that you aren't ready to be an open source contributor. After all, you're just a beginner. What could you possibly offer a project like this one?

I assure you - the little voice in your head is wrong. If you can write code at all, you can contribute code to open source.

You're not the first person to have those thoughts, either. Even the members of the core team of this project have these thoughts from time to time. It's called "imposter syndrome", and it's a really common problem. The good news is - we're here to help you get over it.

This tutorial exists to make sure you know exactly what process you have to follow in order to get your patch merged. In addition to these procedural instructions, this project has a Code of Conduct. This Code of Conduct is there to give you confidence that no matter what mistakes you make, you'll be treated with respect. Everyone makes mistakes - that's a natural part of learning. Our pledge to you is that we are here to help you learn, not to insult or belittle you for learning.

Being an open source contributor doesn't just mean writing code, either. You can help out by writing documentation, tests, or even giving feedback about the project (and yes - that includes giving feedback about the contribution process). Some of these contributions may be the most valuable to the project as a whole, because you're coming to the project with fresh eyes, so you can see the errors and assumptions that seasoned contributors have glossed over.

So - don't be afraid to contribute. If you've gotten this far, you've demonstrated you have an interest in contributing - and that's all you need. We can help you the rest of the way.

About VOC

The idea behind VOC is to take Python bytecode, and compile it directly to Java bytecode. This means your .py file will be converted in a .class file that can be executed in a Java Virtual Machine.

This is useful in a number of possible ways:

• Writing Android applications
• Writing ElasticSearch/Lucene plugins
• Writing Minecraft plugins
• Writing web applications for situations where JavaEE is the only available deployment platform.

It’s similar to Jython in that it allows you to run Python on Java; but it’s different because there’s no runtime “executable” - it’s not a Python interpreter written in Java; it generates Java bytecode that is indistinguishable from code that was generated using javac.

My personal interest comes from wanting to write Android applications in Python; but I hope you agree that there’s lots of other potential uses.

In the following instructions, I’m going to assume you’re familiar with Github and making pull requests. I'm also going to assume some entry level Python and Java; if anything I describe here doesn’t make sense, don’t worry - I’m more than happy to fill in the gaps. At this point, I don’t know what you don’t know :-)

I’m also going to assume that you’re interested in contributing code; if your interests/skills are elsewhere (e.g., testing, documentation), let me know, and I can make some other suggestions.

Before you make your first contribution, I’d suggest taking VOC for a spin. The instructions in the getting started guide should be enough to get going. If you get stuck, let me know and I’ll help you out. And if you get stuck, that will also point to your first contribution - work out what instructions would have made you not get stuck, and contribute an update to the README.

Once you’ve got VOC working, you’ll be ready to make your first code contribution. The contribution guide will guide you through the process of setting up your development environment. Work through that guide until you can run the VOC test suite - once you've been able to run the test suite without any failures, you're ready to add some new code to the VOC codebase.

In order to make Java bytecode behave like Python, VOC needs to implement all the eccentricities of Python behaviour. For example, Python allows you to multiply a string by an integer, resulting in a duplicated string (e.g., “foo” * 3 => “foofoofoo”). This isn’t legal Java, however; so we need to provide a Java library that implements this beheavior.

That particular example (string times number) is already implemented - see:

https://github.com/pybee/voc/blob/master/python/common/org/python/types/Str.java#L309

This implements __mul__() (the Python multiplication method) on a “Str” object. It’s implemented in Java, but it implements Python behavior.

If you then look at:

https://github.com/pybee/voc/blob/master/tests/datatypes/test_str.py

You’ll see the tests for this behaviour. I’ve already written a test suite that tries to perform every operation on every data type. However, all of the names listed in that file are the examples that are known to fail (because the implementation doesn’t exist yet). The tests work by writing a short program that implements one mathematical operation, running the program under normal Python, and then running it again under VOC/Java. The test passes when the two executions produce identical output.

So - your first open source contribution: Pick a test that is currently listed in the test_str test file (e.g., test_multiply_float is the test of multiplying a string by a float), and modify the implementation of Str until you get the same output from CPython program as you do from VOC-compiled version of the same program. This includes error messages - if CPython raises a TypeError for a particular operation (e.g., “foo” * 3.1415), then so should VOC - and the error message should be the same too, right down to the punctuation.

Before you start work, visit ticket #36 and register which function you're working on - that way we won't end up with 2 people working on the same one.

Once you've written your implementation, run the tests. If you get an “unexpected success” from the test suite, and you don’t get any failures, you’ve done it! Delete the line from the test_str file corresponding to the test you’ve fixed (because the test is no longer expected to fail), and submit a pull request!

Then break out a celebratory beverage of your choice! You’re an open source contributor!

If you need help stepping through this, you can grab me on Twitter, or in #beeware on IRC (on Freenode). I’m freakboy3742 on both. Or, feel free to send me an email

Best of luck - and I can’t wait to see your first contribution!