> What is a string?

August 23rd, 2014

Most programming languages have some wrinkles around unicode and strings*. In my ficticious language Pepper, there are no wrinkles of any kind, and everything is perfect.

*E.g. JavaScript, Java, Haskell, Ruby, Python.

There are several key concepts. The most important are an interface AnyString and the variable** String which is what you should use when you are writing code with strings.

**String is a variable that refers to a type, so you just use it like a type and don’t worry about it.

interface AnyString
{
    def indexable(CodePoint) code_points( implements(AnyString) string )
}

In Pepper an interface can describe what free functions exist as well as what member function a class must have, and here we just require that a code_points function exists that gives us a collection of CodePoint objects that may be indexed (i.e. is random-access).

When your Pepper program starts, the String variable will refer to something that implements this interface, and probably some other interfaces too. Most Pepper programs will use a String that is implemented as an array of bytes representing a string in UTF-8, but the programmer doesn’t need to be aware of that, and in a situation where something different is needed (e.g. where we know lots of non-Latin characters will be used and UTF-16 will be more efficient) String can be set to something different in the configuration settings used by the compiler.

When you want to do something with a string, there will be functions that only rely on the AnyString interface and deal with CodePoints internally, but there will be other overloads that are potentially more efficient, for example there are two versions of the standard print function:

def void print( implements(AnyString) string )
def void print( NativeUtf8String string )

The NativeUtf8String class is implemented as a std::string in the C++ code emitted by the Pepper compiler, and the most efficient way to represent an array of bytes when compiling onto other platforms, so the version of print that uses it can be quite efficient.

Because all these types are known at compile time, the C++ code generated by the Pepper compiler can use the native types directly (and be efficient), even though the programmer is writing code using just the AnyString and String types, meaning their code can be adapted to other platforms by using a different configuration.

The Pepper environment exposes standard-out and standard-in as UTF-8 streams, and takes care of converting to the platform encoding for you (at runtime).

> Absolute Truth in programming languages

August 22nd, 2014

Is enforcing truthfulness the opposite of beauty?

Can 2 + 2 = 5?

Improvements, corrections, further contributions are welcome.

$ cat five.cpp 
#include <iostream>
int operator+( int x, int y ) { return 5; }
int main() {
    std::cout << 2 + 2 << std::endl;
}
$ g++ five.cpp 
five.cpp:2:29: error: ‘int operator+(int, int)’ must have an argument of class or enumerated type
$ python
>>> int.__add__ = lambda y: 5
TypeError: can't set attributes of built-in/extension type 'int'
$ cat five.hs
import Prelude hiding ((+))
x + y = 5
main = print ( 2 + 2 )
$ ghc five.hs && ./five
5
$ cat five.rb
class Fixnum
    def +(y)
        5
    end
end
print 2 + 2
$ ruby five.rb
5
$ mzscheme 
> (define (+ x y) 5)
> (+ 2 2)
5

> Options for code reviews with Git

August 18th, 2014

We’re thinking about switching to Git for my work, and I want to be confident we can still support good code reviews if we make the switch.

I am a big fan of in-person reviews, and for that, git difftool is enough but sometimes you need to do it asynchronously, and then you need a tool or a process or something.

Here are the options as I see them so far (please comment if you know others I should consider):

  1. Emailing patches. Git has git format-patch and git bundle that allow creating a file containing changes that can be sent by email or message. These can be reviewed as patches or applied to the working tree and reviewed in context.
  2. Feature branch and pull request. Devs to push their changes to a branch in a shared repo and send an email or message asking a colleague to pull the branch. The reviewer looks at the changes in the repo or pulls them, then either sends back comments, or merges the branch into their own and delivers to the master branch.
  3. Tools. There are several extra tools that sit in front of Git and deliver changes when they are reviewed. These include: Gerrit, Critic, Review Board.

References:

> Desktop sharing not working in Lubuntu 14.04

August 12th, 2014

On my recently-upgraded to 14.04 Lubuntu machine, desktop sharing didn’t work.

Here’s how I made it work:

Once (to allow some Windows clients to connect without encryption):

gsettings set org.gnome.Vino require-encryption false

Then every time I want to share my desktop:

/usr/lib/vino/vino-server

and leave that running while I’m sharing.

> Best GCC warning flags for compiling C++

July 18th, 2014

A recent discussion on ACCU-general gave people an opportunity to share the warning flags they like to use with g++.

I thought I’d write down the consensus as I understood it, mainly for my own reference:

-Wredundant-decls
-Wcast-align
-Wmissing-declarations
-Wmissing-include-dirs
-Wswitch-enum
-Wswitch-default
-Wextra
-Wall
-Werror
-Winvalid-pch
-Wredundant-decls
-Wmissing-prototypes
-Wformat=2
-Wmissing-format-attribute
-Wformat-nonliteral

We were advised by Jonathan Wakely that -Weffc++ is not very useful since it is mostly based on the first edition of the book Effective C++, many of whose recommendations were improved in the second edition, and also apparently GCC doesn’t do a great job of warning about them.