Developing with SublimeText continues to be a pleasure, except that curious interaction with virtualenv and ST’s build system. I seem to have two choices:
- Create a new build system for each virtualenv – which is pretty much 1:1 for my projects. When switching between projects in ST, don’t forget to change the build system, too.
- Use 1 build system for python, but every time I switch projects, edit the build system with the proper python target. No initial setup, but I’ve got to keep the build system open and remember where the venv is.
Enter PyProMan. Basic, but it gets the job done and there’s almost no overhead if you decide later that you don’t want to use it anymore.
Put your projects in the $PROJ folder, and get started with a new virtualenv by running “proj pythonX.X” from that folder. For the project “foo” there will be a new virtualenv in $VENV/foo. Now, you can interact with any projects’ appropriate bin/ scripts by putting “proj” before the command (much like sudo). Want to install a package for the project you’re in? “proj pip install some_package” and it’s done.
But wait there’s more
The real reason this was put together was to make the SublimeText integration trivial. Since our build system will always run the script we’re building from the project folder it lives in, we can use the same exact build cmd for all projects. We don’t have to create and manage multiple build systems, we don’t have to edit it when switching projects. “proj python $file” will figure out the appropriate python interpreter and hand it the rest of our arguments. And we can use that command outside of the project folder as well, and still use the right virtualenv. As long as you have put proj before python when executing a script, you can be sure it’s executing in the right environment.
Wow! Anything else I should know?
Not really – two environment variables and two small bash scripts (that could be one). For more information including my full SublimeText build system, check out the readme at https://github.com/numberoverzero/pyproman
This post we’re going to focus on the third point of our requirements. To recap, here they are:
- Many values fit in one or two bytes at most – booleans fit in a bit, color channels fit in 1 byte. Any solution needs to allow bit-width specification.
- However, I shouldn’t need to specify the bit-width of every value. Reasonable defaults should exist that can be dropped in where appropriate.
- Serialization shouldn’t get in the way, and I shouldn’t have to give it much thought when I write my classes.
- Of course, I should be able to drop into the details when a class requires custom serialization.
- Performance overhead, both time and space, should be as low as possible. Per-instance overhead is almost entirely unacceptable.
- Serializable classes should be nestable, and the performance overheads for nested classes should be as low as possible.
We’ll first take a quick look at the code the last post finished with – hopefully the problems we found can help design an interface that more closely fits the third point, while keeping the fifth (performance) in mind.
I made a quick housekeeping sweep of the blog recently, and wanted to revisit the Collatz Conjecture. I’m sure it’s been suggested before, but I believe there’s another method of proving the conjecture:
for all where
That is to say, we only need prove that for an n > 2, all integers between consecutive powers of 2 resolve according to the collatz conjecture. I’m not sure where to go from there, but for instance we can show that in general:
where r is the number of (divisible by 3) iterations such that
I ported the Iterative Diamond-Square Algorithm from Python, and added a few features.
The biggest addition is interactivity, and the biggest optimization is using shaders for updating/drawing. If I have time in the next few days, I might try to move the random generation to a shader. Shouldn’t be to hard, and it would be a significant gain in speed. In the meantime, I’ve got generation running on a separate thread (thank you C#’s anonymous functions!)
The code is available on Github. Follow the break for usage instructions, screenshots, and code highlights.