Introducing... "WhioDoc" (formerly "Quack!" / "QuackDoc")

I guess this weekend can be considered somewhat successful on the projects front (even though I only really got around to 1 of the 3 projects I'd wanted to work on, though it *was* the most important one I wanted to knock off too)

Following a few sessions of toil, I have successfully put up an initial attempt at formalising all the conventions I've been using for writing inline code docs for all my projects over the years!

While there are still a few small loose ends to tack on, at least I can finally point to this thing and say: Here's the spec!

(And eventually: "Here's all the docs-compiler tools + editor plugins everyone asks for these days")

 

https://github.com/Aligorith/quackdoc

https://github.com/Aligorith/whiodoc

 

Python 3.11 - IntEnum str() representation changes

Got an unwanted surprise today trying to run my codebase ("TPMS Studio") using the latest Python (3.11) instead of the 3.7 / 3.8 combos I've been using for the past few years.

Turns out the core team made a breaking change to the behaviour of enums, which breaks our file format + causes the code to crash on startup (assert failures)!

The cause:
`str(eMyEnum.Value_1)` now evaluates to "1" instead of "eMyEnum.Value_1"

(Note: eMyEnum is defined as an IntEnum)

 

The solution I ended up with was based on:
https://github.com/python/cpython/issues/94763#issuecomment-1313058070

 

[EDIT: This was the old solution. I have since learned of an even easier fix, from the official docs. See below]

In short, I now do something like:
```

import sys
import enum

if sys.version_info >= (3, 11):
    # Python 3.11+ hack
    class IntEnum(int, enum.Enum):
        # Get back old "EnumName.VariantName" str() behaviour
        pass
else:
    # Use old defines for older Python versions
    IntEnum = enum.IntEnum
```

 

[Latest Update: This solution is easier to use. It comes from the official docs (i.e. example 2)]

```

from enum import Enum, IntEnum

class eMyEnum(IntEnum):

    __str__ = Enum.__str__      # <--- That's the key right there

``` 

 Reposting from my original Mastodon posts for easier searchability

VMWare - Getting copy-paste support working

While doing some work in a VM today, I discovered, much to my chagrin that VMware was not allowing me to copy text from the VM back out into the host machine! As can be imagined, this is a massive pain if you're trying to Google a frustrating error message, or even to extract the error logs to file bug reports.

The method I'm reposting here has been tested to work with "VMware Workstation 16 Player" (16.1.0 build-17198959) on Windows 10. I'm reposting it here mainly so that I can find it again easier the next time this breaks, but also since the original post may end up going away (given that shabby state of the forum it's hosted on).

 

Original Link (by "pyhoff")

https://communities.vmware.com/t5/VMware-Workstation-Pro/Copy-paste-not-working-in-VMWare-Workstation-15-Pro-after-the-15/m-p/1841561/highlight/true#M109372

 

Steps:

1) Ensure the VM isn't running

2) Locate the "Virtual Machines" folder. It should be under your Home Directory / Documents folder.

3) Navigate to the VM in question

4) Open up the ".vmx" file in a text editor

5) Add whichever of the following defines are missing from that file  (I just added all of them):

isolation.tools.copy.disable = "FALSE"

isolation.tools.dnd.disable = "FALSE"

isolation.tools.paste.disable = "FALSE"

isolation.tools.hgfs.disable = "FALSE"

6) Save the file and start the VM again

7) Bi-directional copy and paste should now be working.

Draft Feature List for Aligorith's Unnamed/Hypothetical Programming Language - 2019 Edition

Perhaps it is finally time to think about creating my own programming language? It would be that long-term passion project that I can truly have complete control over, with the potential for truly minimal dependencies, and in which I can finally build that proper "property system" + "node evaluation engine" + UI toolkit" that will fully work the way that I want it to, and then use this as the basis for all the projects in my backlog which will require similar structural/framework support.  (I could also formalise that documentation system I've been using on all personal projects - the one I documented here once many years ago).

I'm not that crazy yet...   yet!

Then again, I have been thinking about these matters more and more over the past year, so it's highly possible that this may still happen. If I can muster up enough time/energy away from everything else I'm working on (OR if external constraints expedite this process for whatever reason).

So, if I was to write my own programming language/environment, what can you expect it to have. Here is an incomplete list of the important things I'd do.

Struggles of a Rust Novice - Annoyances and Stumbling Blocks

Over the past few weekends, I've been spending time investigating more of the Rust language. Along with the web trifecta (HTML, CSS, JS) and OpenFrameworks, this is one of the things I've been meaning to spend some time learning/playing with this year.

It's a funny kind of language, as I've previous noted during my very brief foray into some simple things from last year) - On one hand, a lot of the concepts seem nice/vaguely familiar to stuff I've played with in other languages, making it sometimes feel deceptively easy to use. But then, you go to compile the code, and proceed to spend the next 30-60 minutes trying to find a way to convert various things into the right types that the compiler insists you need. Admittedly, it's quite frustrating work at times (see notes on String handling below), but, it pales in comparison to the blackhole and deranged hell that is web-based dev (i.e. CSS-based Layouts in particular - aaaaaaargh!!! Despite now having "CSS Flow" and "CSS Grid", it seems that CSS Layouts and I still don't get along very much at all). Faced with a choice between the two (and having just done experienced both back-to-back recently), I'd much rather face the Rust compiler anyday.

Anyway, to actually get a proper feel for the language this time, I decided to use this opportunity to bash together a little processing tool that I was going to need for another one of the many projects I'm working on atm:

That is, a tool to take XSPF playlists generated by VLC (and containing a carefully sequenced list of music I've composed/recorded over the past year), extract the filenames (and process them to unpack/extract-out the important identifying bits of metadata I was embedding in the filenames), and then spit all this info out into a more easily consumable format (e.g. JSON).  

Sure, I could've done this all in Python (though it lacks a XML library that just gives me the DOM element tree with no "namespace" tag mangling, etc.), or a mix of VLC + Python (i.e. saving out a m3u list - 1 line per track - then processing that in Python), but this way was going to be more fun (and a good way to throw something a bit meatier/realistic at Rust than the toy-examples I'd been playing with) :)


Hopefully the following post will be enlightening to some people out there - both other newbies stuck and struggling to get their heads around certain things they keep running into, but also for the Rust dev team in their self-professed "ergonomics drive" to lessen the humps that new devs face when learning Rust.

"Hex to RGBA" and other Colour Conversion Tools for Sublime Text 2/3

Today I'm announcing the first release of a new plugin for Sublime Text 3 (ST2 untested, but may well be supported too, *fingers crossed*) that makes it easier to work with various colour representations in code. As anyone who spends any time working with various colour pickers and colour-related API's on different platforms knows, at some point you're going to have to convert your colours from one representation to another for some reason, and then you suddenly have to waste heaps of time converting and transcribing colour values between different representations. Clearly this can be optimised (we're using modern text editors for goodness sakes!)  So, without further ado, the plugin can be found at the following Github repo:

https://github.com/Aligorith/Hex-to-RGBA

Key Features:
* Convert Hex (i.e. #RRGGBB) color representation to a RGBA tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1))
* Convert RGB(A) tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1)  OR rgb(0-255, 0-255, 0-255)) to Hex (i.e. #RRGGBB)
* Convert individual colour values from 0-255 (unsigned byte) values to/from float (0.0-1.0) values
* Accessible from menus (shown in screenshot), using hotkeys (shown in screenshot too: Ctrl-Shift-R for "Convert to rgba", and Ctrl-Shift-H for "Convert to hex"), and from the command palette (Ctrl-Shift-P - I recommend searching for "hex" or "ub")

EDIT (20180215):  I've just tested it in Sublime Text 2, and it also works there. So, it's safe to say that it works on both now :)

First Steps with Rust

A few days ago, I suddenly got the urge to download Rust and have a little play around with it. Truth be told, I've been hearing some good things about it, and seeing as they now have a stable version out, I felt it was finally time to give it a little play around.

So far, I've played around with it for about 3 days. There's still a lot I don't know about the thing, but at the same time, I now have a decent feel for some "everyday aspects" of coding in this language.

QML Tip: Making one ShaderEffect use the output of another ShaderEffect

I've been doing quite a lot of work in QML lately for one of my research projects. Recently, I ran into some problems when trying to use ShaderEffects to actually apply them to "interesting" widgets/elements (i.e. on to anything that's not an Image and/or is more complicated than just a simple Rectangle). This post is just a quick guide to some of the key issues here (and ways around them), since it's not exactly that obvious from the documentation that this is the cause/solution, and no other hits come up about these issues...

Useful Tip: Changing command line prompt on Windows

I just came across a useful little trick this afternoon for making the Windows command line prompt (i.e. the one you get when running cmd, which shows the current directory) much shorter  (heck, you can set it to anything you like even!), so I thought I'd just note it here so that I can look it up again should I forget in future.

prompt [new_prompt_goes_here]

That's it! Just type this little command, and it will change the prompt that gets displayed.

Bendy Bones Dev Update

It's been a busy few months since I first announced that I was working on bringing Pepeland's Improved Bendy Bones to Blender. After being tied up with many other projects for the past few months, I just spent the weekend having a fun hackathon to get this functionality polished up and ready for general use in Blender proper. Along the way, I've also added a few cool new features, which really take B-Bones to the next level! Here's a sneak peak of some of these in action!

In each of these screenshots, you're seeing just a single B-Bone - no hidden stuff, no tricks. Just a single B-Bone...

UPDATE: It's now in master! (After a little fight with git to let me merge the branch successfully...) Woohoo!

GPencil - Using bpy to generate strokes programatically

In response to a question on BlenderArtists this morning, I spent a few minutes poking around with the Python API to check whether it is possible to generate GPencil strokes using a script.

Example output from my test script - It just generates a set of 5 lines in 3D space as a demo of how to use this api

For the benefit of everyone, I've included the test/demo script I wrote at the end of this post. You should be able to just copy and paste it into a text editor (fingers crossed it doesn't grab any of the HTML crap in the process) and start playing around.

Use cases for being able to create Grease Pencil strokes using Python include loading in stroke data from other apps, or for providing addon developers additional ways of adding in-viewport annotations without having to hack around with bgl and draw handlers.

DRY considered harmful

Increasingly, I've been coming to the view that the DRY (i.e. Don't Repeat Yourself) principle is something that ends up being far too easy to abuse/overuse, leaving you with piles... nay, nasty tangled rose thickets of complexity that quickly snowball out of control. In fact, I'd go so far as to argue that our "cures" for this - templating, generics, class hierarchies + networks (i.e. basically most "OO") - only make things worse most of the time, especially when everyone starts lauding them as "silver bullets" when the see them.

Another probably controversial and related view I've arrived at in the past few years is that I now consider nested/chained event callbacks as evil - it only takes one or two run-ins with these to realise that it really sucks when you have a UI which inexplicably starts running slow as molasses and has a penchant for double/triple redrawing itself with a very visible white/blue flash each time, only to find after hours and days of blood curdling debugging that this is because the callbacks start becoming unintentionally reentrant by calling each other repeatedly...

For an all too familiar take on this, see: http://www.benkuhn.net/rha

Put simply, DRY applies a LOT less than you probably think it does! In fact, it can hurt readability faster than if you'd just left all the repetition in there..

Text Editor Project Started

With a long weekend holiday here, I finally bit the bullet and started work on building a new text editor for myself. This comes after years of trialling different solutions - including giving some of the latest newfangled web-tech based ones out there a second chance with an open mind (in the end, a combination of critical quirky flaws and horrid colour schemes inducing eye pain - including one nasty bout of red-eyed discomfort for a few hours) as replacements or "secondaries"... Unfortunately, nothing is quite cutting it anymore :/

So, introducing "Nippy" - a PyQt + QScintilla based text editor, heavily inspired by Notepad++

https://github.com/Aligorith/nippy

Currently, there's not much to see. It's only a single-document text editor window right now, with a lexer hardcoded to treat everything as Python code, and with no session storage. But at least I can use it to load up any of the code for my Python-based projects, and use it for some simple coding tasks (bookmarks, duplicate-lines, move up/down, go to line, tab-based indentation, and file open/save all work, with the rest provided by QScintilla already - in other words, the bare basics I need from an editor to do stuff; a working function list + find in files + multiple tabs would just make things easier).

Dev Ramblings - Grease Pencil OpenGL Render Exports

While doing some testing of the Grease Pencil functionality last week, I came across some weird/unexpected behaviour regarding how some of the OpenGL renders were working. As many will know, these are currently the only way to get Grease Pencil drawings out of Blender. And as I found out, there are quite a few annoying quirks that I came across, the most serious of which is shown below:

Blegh! What is up with those regions that are completely transparent, and fringed with light gray?!

Blender Dev Tip: Modal Keymaps for Select Circle

Doh! The answer in retrospect seems so simple (and it was, if I'd remembered this quirk from the last time I'd encountered it several years ago), but you'd be stuck if you didn't know where to look...

For a bit of a fun break from the work I've been doing recently for my research work, I've been hacking some new features for Blender. However, this evening, I ended up wasting quite a bit of time trying to figure out why the circle-select operator I'd been working on was not working. Namely, it wasn't responding to any events once activated.

Long story short: If you're coding a "Select Circle" operator, you need to add the following line at the end of gesture_circle_modal_keymap() in wm_operators.c:

WM_modalkeymap_assign("<your_operator_id_name_here>");

This basically says that the modal keymap needed by these operator should be used when doling out events to your operator. Otherwise, the events simply won't get passed down, and you'll be left wondering why it's not working...

Video Link - Robert Hodgin at Eyeo 2014

This evening, I came across an entertaining talk by Robert Hodgin at the Eyeo Festival this year, about his work on flocking simulations. "Creative coding" (i.e. interactive/dynamic scenes) definitely sounds like some fun stuff to play around with sometime...


Eyeo 2014 - Robert Hodgin from Eyeo Festival // INST-INT on Vimeo.

Getting the itch...

It's been a long time since I've felt "the itch" - that burning desire to do some real graphics coding which spurred the weekend-long hackfest resulting in Spline IK for Blender, or starting down the road which ended in Blender being the first publicly available animation package (we were pipped only by DigitalFish) to have a builtin & integrated Grease Pencil tool. (Incidentally, it's not too much of a coincidence that I mention these two projects, since they have certain links to what's brewing...)

Perhaps it's been the warm, sunny, and positively summery weather we've been having the past few days (spoilt only a bit by the braindead moronic lowlife thuggish bastardly boorish yoof-slobs we have as neighbours, who decided to have an unattended open fire burning away under their barbeque on Saturday night, mere meters away from our fence and house, with occasional strong gusts of wind still picking up from time to time, forcing a change of dining plans to keep a cautious eye out on their activities lest there be any 'accidents'). Or maybe it was watching the steady stream/flurry of new hairsim development commits coming through my mailbox over the past week.

Regardless of the cause, I'm now itching to get back to a project I hold dearly. This is especially true now, having come across any exciting new paper, which lays out the groundwork for getting past one of the issues which had stumped me on my previous attempt. It's now so much closer to being a reality... I just hope/wish I can siphon enough time out of my research commitments to work on this... Argh! The creative tension is killing me!

Experiments with QML and Vim

This weekend, I've been having a lot of fun playing around with QML, and doing so in Vim (instead of my usual Notepad++). Chances are that you probably haven't heard of QML before (or if you did, your projects at the time wouldn't have really benefited from it, given that it does have limitations when it comes to being able to use standard widgets).

QML is basically a "declarative" language for defining dynamic UI's, built on top of the Qt Framework. It's syntax is like a nicer version of CSS, with the ability to throw snippets of Javascript in when needed to define small bits of custom logic when needed, and (if it's hosted via PyQt) you can even code up any of the more "tricky" or substantial logic in Python, then use the PyQt QObject bindings to make this available to your QML code.

Although it doesn't come with a fully fleshed out widget set that you can use (though apparently, this is only true for the PyQt4/Qt4.x that I'm still using, as they've developed a set of widgets for that purpose in Qt5), it more than makes up for that in terms of what it enables you to do instead.

Basically, if you're looking for a lightweight domain-specific language for defining/prototyping little graphical scenes, complete with dynamic behaviour (i.e. procedural animations, animation effects, and transitions in response to user input), and the ability to compose/package up you creations as reusable assets, look no further. This toolkit is for you!

FAQ/Rant: Learning your way around a new codebase

From time to time, we get emails and forum postings asking about how to get started developing Blender. These almost always follow a similar predictable pattern (no offense to any individuals whose posts actually resembled this almost to the letter):

1) Blender is cool. I want to write some cool new big feature (*A) or fix some bugs (*B).
2) I've experience in C/C++/Python/Java/OpenGL and/or have taken classes in C/C++/OpenGL/matrix math (*D)
3) I'm trying to understand Blender's source code. The source code is so large that I don't know where to start (*A+E) / the "learning curve is too steep" (*A+D+E) / I tried stepping through the code in a debugger and it's too complex/hard to follow (*D+F) / it's weird/confusing (*D+F+G)
4) HEELLLLPPP MEEEEEEEEE!!!!!!!!!!!!!!!!!  PLZ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Notes on Windows Hacking - Identifying File Browsers and File Dialogs

If you stumbled across this post looking for information about how to identify File Browser windows (i.e. "explorer.exe" instances) and File Dialogs (i.e. Open / Save As dialogs), here is what you need to know:
- GetClassName(hwnd, className, nameBufLen)  or  className = win32gui.GetClassName(hwnd)  in Python with PyWin32 installed  gives you a string for identifying the type of window you're dealing with.

- CabinetWClass = The identifier for File Explorer windows
   - "Rebar" is the navigation toolbar containing the back/forwards, breadcrumbs, and search box
   - "Control Host" the shortcuts pane where favourites, libraries, and the folder hierarchy are shown
   - "Shell Folder View" is the pane where all your files and folders are shown

- #32770 = The identifier for Folder Dialogs (such as Open/Save dialogs)