Helping hands

Phix is an open source project, and warmly welcomes any additional pairs of hands and eyes, especially on Linux.

Assuming you have installed Phix and used it a little bit:
1: run "p -cp" (or './p -c p' on Linux), as further detailed (if needed) in installation. (~20s)
2: run "p -test" (or './p -test' on Linux) to verify the new version of Phix you have just built all works correctly. (~10s)
3: run docs\phix\makephix.exw (~30s), and on Windows open docs\phix\phix.chm, or on Windows|Linux open docs\phix\phix.htm.
4: visit https://openeuphoria.org/forum/index.wc and make sure you can log in and post.

Congratulations, you are now a fully qualified developer/maintainer of Phix!

Of course Phix is not exactly trivial, and it is perfectly normal to feel overwhelmed and/or out of your depth.

The first thing you need to do is get over inline assembly - while you could take a deep dive into and spend forever and a day learning all that stuff, it is also perfectly acceptable to quietly gloss over that, and just accept it is there and you ain’t gonna touch it, at least not for a good while yet anyway. You may want to do something a little more crazy: modify Phix\builtins\VM\pLen.e - just type say "garbage!" somewhere (remembering to save the file!) and see what happens when you try step 1 above, before (obvs) undoing that change. The failed rebuild won’t have damaged anything, but should have given you quite a bit more confidence and made everything much less terrifying. Obviously backups are always a good idea, but needed less than you might think.

The second thing you need to do is get it into your head that untested modifications are worse than useless. It is all about testing, testing, and more testing. If some fancy feature works great nine times out of ten but fails in just one case, it ain’t going in, and you’d rightly be annoyed if anyone else’s failures got in. Any proper enhancement is code+tests+documentation, and usually nothing less than all three will do, plus consistency on Windows/Linux/p2js, which may be/need more of a joint effort.

When modifying the compiler sources, it is usually best to use "p p test" first, to run an interpreted copy of the updated compiler, and "p p -test", and then once they both work move on to "p -cp; p -test; p test". Also keep an eye on how long "p -test" takes, to check you haven’t just accidentally spannered performance. In some cases you may have to break it down into smaller steps: a few times when renaming/replacing things I’ve had to rebuild half a dozen or more times, and only been able to remove the old no-longer-used code on the final cycle. Ultimately the Phix compiler is just a normal program just like any other you might write in Phix, albeit probably a little bit more complicated.

The probably long journey from "just qualified" to "experienced expert" is just a matter of experimenting and testing, with help when you need it, and learning to accept the almost inevitable cul-de-sacs and blind alleys along the way. On the other hand there are no doubt plenty of "little things" I have simply missed, even trivial fixes to typos and misleading comments will help.

That’s it, really. Most discussions, suggestions, questions, advice, and updates should ideally all go via the OpenEuphoria forum linked above, or failing that you could try opening an issue or submitting a pull request on https://github.com/petelomax/Phix. Welcome to the team!

Some quick design scribbles can be found on the sub-pages, feel free to start something else entirely.