Introducing Glory
Glory is the code name of my prototype IDE for developing OpenGL-powered graphical effects. After half a year of work, it has entered a functional alpha stage (and awarded me the MSc.)
Glory is the code name of my prototype IDE for developing OpenGL-powered graphical effects. After half a year of work, it has entered a functional alpha stage (and awarded me the MSc.)
Unicode is a standard that defines several things. Here is a handful of some most important facts about it:
I couldn't read my Git history today because I ran into this problem:
$ git log --oneline f1330fd Basic automation 7234c6e Textures work 3b18493 Fix combo defaults error: inflate: data stream error (incorrect data check) fatal: loose object 65d626bb82c8996f8fc5f659f7c207fee1d74948 (stored in .git/objects/65/d626bb82c8996f8fc5f659f7c207fee1d74948) is corrupted
The same message appeared when checking the repository with git fsck
.
My working copy and dozens of last commits were intact; this error showed up when trying to view more history or when trying to clone a repo. Some googling revealed that I should get the original (non-corrupted) object from somewhere and replace it.
So you want to make a project with the advantages of native code. You like the performance of fine-tuned C, you need some heavy pointer juggling or bit fiddling or SSE, or perhaps you just dream of the vast lands of C libraries available around there. But you're in love with Python and really want to be able to glue your app together with elegant high-level code. Hard decision? Definitely.
But why can't we have both? Using two languages together introduces complexity, but might have good payoffs for your project. Give it a shot.
A closure is basically a function that was defined in some local scope and has access to the local variables from that scope. Additionally when a closure (the function object) outlives the scope where the closed variables were defined, their lifetime gets extended (or not, depending on the language).
I find closures wildly useful, especially in prototyping. They also are welcome in production code, if you don't get too carried away. However they are not exactly as intuitive as one might expect and if you decide to use them there's a handful of details you must remember not to introduce bugs.
This article has two parts:
Also for a quick recap on closures see this gist.
Behaviour of Python objects can be customised in tons of ways using special functions. This article describes some of them, all confusingly starting with __get
and all having drastically different purposes.
Python 2 has some interesting pitfalls related to slicing. They have roots in the old Python versions before slice objects were introduced. The syntax has been improved since then, but some little gotchas are there and ready to bite you in your knee at the most unexpected moment. Tomer Filiba describes one such scenario.
See also this gist for some illustation what's happening.
This article describes special method lookup and shows how it differs between old- and new-style classes in Python 2.
The docs say that...
For old-style classes, special methods are always looked up in exactly the same way as any other method or attribute. (...) For new-style classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object’s type
I'm going to elaborate on that a bit.
... or at least think twice before you do.
audience: Computer graphics students and OpenGL enthusiasts
This article shows how to load and use dynamic libraries in Python, taking OpenGL and GLFW as the example. While some code is Windows-specific, the guide relates to other platforms too.