Hopefully it was helpful – there were several good questions, so I am optimistic that people were engaged with it.
After that, there was an excellent talk by Gareth Lloyd called “GeoPandas, the geospatial extension for Pandas” in which he explained how to use the very well-developed geo-spatial data tools available in the Python ecosphere to transform, combine, plot and analyse data which includes location information. I was really impressed with how easy the libraries looked to use, and also with the cool Jupyter notebook Gareth used to explain the ideas using live demos.
London Python Meetups seem like a cool place to meet Pythonistas of all levels of experience in a nice, low-pressure environment!
Continuing to explore the Godot 3 game engine. I want to make a game where you drag blocks around and balance them on each other, but I couldn’t find much documentation on how to drag-and-drop objects (except menu UI elements), and especially I found quite a few wrinkles when doing this with objects that are normally controlled by the physics engine.
This time we actually write some code in Godot’s programming language, GDScript.
I’m running a workshop at the Egham Raspberry Jam on 21st October. The workshop will introduce my little animation language Graft. We will tell a story using animations that we created ourselves using code.
The worksheet for the workshop is here: PDF or ODP.
Adapt to the changes in the Regex module – 856762a4
Stop using tuples with more than 3 parts – 472c0bb7
The lack of Debug.crash is really, really painful, especially for a library like eeue56/elm-all-dict that has lots of invariants that are hard or impossible to enforce via the type system. On the other hand, if Elm can give a hard guarantee that there will be no runtime errors, this seems pretty cool. The problem is that some code may well have to return the wrong answer silently, instead of crashing, which could be much worse than crashing in some use-cases.
I was annoyed by the lack of more-than-3-part tuples, but even as I did the work to change my code, I saw it get better, so it’s hard to argue with.
The hardest part to work out was how to run the tests. Fortunately the tests themselves needed almost no changes. I just needed to do this:
Groovy has lots of interesting syntax that can be used for domain-specific languages, such as Gradle build files, and Jenkinsfiles. I try to demystify the syntax tricks a bit so you have a chance to read and understand what the code is actually doing:
I am trying to practice documentation-driven development in Pepper3, so every time I start on an area, I will write documentation explaining how it works, and include examples that are automatically verified during the build.
I’ve started work on lexing, since you can’t do much before you do that, but in fact, of course, I need to have a command line interface before I can verify any of the examples, so I’m working on that too.
Lexing is the process that takes a stream of characters (e.g. from a file) and turns it into a stream of “tokens” that are chunks of code like a variable name, a number or a string. (There is more on lexing in my mini programming language, Cell.)
My thoughts so far about lexing are in lexing.md, and current ideas about command line interface are at command_line.md. All very much subject to change.
Ordinary programmers can write their own lexing rules.
Operators (functions like “+” that find their arguments on their left and right, instead of between brackets like normal functions) are defined at the lexing phase, so any symbol (e.g. “in”) can be an operator if you want.
Anything you might want to do with a pepper program, including running it, compiling it, packaging it for an distribution system, should be available as a sub-command of the main pepper3 command line.
The command is “pepper3”, never “pepper”. If a new, incompatible version comes out, it will be called “pepper4”, and they will be parallel-installable, with no confusion.