Phillip Trelford's Array

POKE 36879,255

Procedural Invaders

Procedural invaders are space invader like characters generated as 5 x 5 pixel characters from just 15 bits using symmetry. The earliest post on procedural invaders appears to be from a J Tarbell in 2003. Thanks go to Ross McKinlay for suggesting having a look.

Below are some sheets of randomly generated invaders with generated names that you can click on to generate a tweet with F# code that generates the invader as ASCII art when sent to Mathias Brandewinder’s @fsibot.

invaders ocodehkiauoyemixuoocuucenotiyofecalepergucjucjoxnoxebatigzuyanitiereypunefegaajusaacorgipciguweejeqemaulaiborruxuvawedayamgasihhedlorifuaelioixejqabexiqiiboquaiwazavvijuzapbuiouxompoqqesonteuitocijwuwtalmufefuysurbuwpujxorroirajjokijgobfibqeejiokusiporixxokajavgolcoqeloooviwemisaguxovegnujepfequpeuaiutoazeleinijtirqenqaesiozawufafuaavexuzumiupomrijeeqipokeeaumehmooezuxixifihohaicebyezboiniokamugucar

invaders

uleraitupisurleyfopupitqohteerodeguzocvunujqeracaciugiktufewkomigepdufuqwoesusahawayuyrayutixezajexowusqixtomurexhaquobepruomagxiihookuzidomexixiuqoqekoyohviiuyugajihakqubseqeweficosepbieebafaaouheeguqkoogamvabbenpoaouoivifhivesjeecoiduvooauuuveuwirigguqfoakedzoovogxekbalerokitukilimfitjeqarwomiiaonoporgaketagmovuharuarobbanaepuiodaskueajudpeluqoejazosowmeafivxureroxoqroralurotemaearuunafionedqelamfopimukagaxesiscivusamazezalafowosanamutitozunimihodlerduaiupirufeniyakmoeuwaneujeboisiasoleutuserquwazalifqukotjisasojukniqetejeuxocemeaqupjevkefewerarzifaeyovarejuguieiofaqeqiqoyilaphapaoacorzowoibavwosgoakugmuxwahoeweakiizownaqootimqamufutoulimoziecoyumuxuwubovezoynonitlargusiycibqudubueerunleceisiayojaehofayiruuukecamayuaenebuxmoviigosyoyretluqmakirhufoydoruweibihalureociycokuszaanozounuquvofenahyurezzeqhepevcagefhizseupivxigulifohdoleaugoyefageoiuemenvucexinucolayyiwbuzuweluhivqumbizevugeoziucovixufuwusemkoluhikkuykiqindecculapereyoiyigamuxomoppeleorawxunnoqdaxyuvooaituelugoufejayisootauwujzomouuegujefubaomepuvopecitobyoctalqufcirishuspijutisagezuuzayaokobyejigomigeorillehbepsoqezojoyulupazuuedenoxzuscafjiaweoetufeginukgixhoskimadogualexnirmirayapofaqafauwivluwqikhidqewboeepihihawudhebakoecoekadgaweryeguiavadepealowagnuhuwavhoecuqihquvaauwoxtupodengodbecazadopuootadxiblabweeuzaoqiqejeelusosiszohzoruhaoceuqieyadibjinilimufimrasyizuqiovopfayeturoqobitiooayezqozeiisictaufijyovtelivasuvejeaaiouopeteuhurisumxakqivuqeecuavezdaduxiyifawohjumerkihpogquhoqaxuttuvilucewyupgohisfesqipcojdafopoffeduroaiiucadbixufguvebisufataufaysesruwauyipilusxiyalatgugerabxuoweuwufumvadierevicununofipojeofofouehilmorser

Techie bit

The sheets of invaders are drawn on to a bitmap image and saved as a png file (see invader bitmap generation F# snippet), with the bit pattern for each invader generated from the hash code of it’s generated name (see pseudoword generation F# snippet). At the same time a matching HTML image-map is generated with the coordinates of each invader with a link that generates a tweet for the specified name.

 

MSDNify Types

Following on from yesterday’s post on Disinherited Types where I implement an F# type provider that hides inherited members of a type to let you focus on the useful members. The example was the WPF Button control which contains around 300 members via 9 levels of inheritance and appears to flout the object-oriented principle of composition over inheritance.

Microsoft’s MSDN documentation takes another approach to the problem of making relevant members discoverable by grouping members by type, i.e. all properties, all methods, all fields and all events:

Button class docs

MSDNify Type Provider

To give the same discoverable experience in the editor I’ve created the MSDNify Type Provider that groups members by type:

Button by member type

From the filtered member type groups you can select the member you are interested in:

Button events

This in effect mirrors the MSDN docs making it easier to find the useful members.

Source Code

The implementation is very similar to the Disinherited Type Provider discussed in yesterday’s post.

The code is available on GitHub: https://github.com/ptrelford/MSDNify

Disinherited Types

One of the things that’s always bugged me when using Windows UI libraries like WinForms and WPF is the sheer number of members that pop up in intellisense for a control. The Button type in WPF has around 300 members and a total of 9 levels of inheritance making it hard to find the useful members. Or to put it another way the inherited members occlude the useful members:

Button members

The picture above shows what you actually see in the code completion box in the editor, however for a button you’re probably more interested in the Click event, but that’s several pages away.

Disinherit Type Provider

As a thought experiment I’ve implemented an F# Type Provider that hides type members after a specified level of inheritance:

Disinherited button

In the picture above the members now almost fit in a single page. The last property, not visible here, is an extra property added by the type provider that provides all the hidden members for the instance:

Button instance

 

Type Provider Implementation

Underneath the covers the type provider takes an assembly name as a static parameter and optionally the level of inheritance to expose.

[<Literal>]
let name = @"PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
type WPF = Disinherited< name , level=1 >
let button = WPF.Button()

The provider then reflects over the types in the assembly and creates a proxy type as a provided type and exposes members that are declared within the specified inheritance level.

To provide the member we simply create a corresponding provided member with an expression that evaluates to the underlying type’s member:

    let addMember (def:ProvidedTypeDefinition) ty (mem:MemberInfo) =
        match mem.MemberType with
        | MemberTypes.Constructor ->
            let ci = mem :?> ConstructorInfo
            let c = ProvidedConstructor(toParams ci)
            c.InvokeCode <- fun args -> Expr.Coerce(Expr.NewObject(ci,args), typeof<obj>)
            def.AddMember(c)
        | MemberTypes.Field ->
            let fi = mem :?> FieldInfo
            let field = ProvidedField(mem.Name, fi.FieldType)
            def.AddMember(field)
        | MemberTypes.Property ->
            let pi = mem :?> PropertyInfo
            let prop = ProvidedProperty(mem.Name, pi.PropertyType) 
            prop.GetterCode <- fun args -> Expr.PropertyGet(Expr.Coerce(args.[0],ty), pi)
            def.AddMember(prop)
        | MemberTypes.Event ->
            let ei = mem :?> EventInfo
            let ev = ProvidedEvent(mem.Name, ei.EventHandlerType) 
            ev.AdderCode <- fun args -> Expr.Call(Expr.Coerce(args.Head,ty),ei.GetAddMethod(), args.Tail)
            ev.RemoverCode <- fun args -> Expr.Call(Expr.Coerce(args.Head,ty), ei.GetRemoveMethod(), args.Tail)
            def.AddMember(ev)
        | MemberTypes.Method ->
            let mi = mem :?> MethodInfo
            if not mi.IsSpecialName then
                let m = ProvidedMethod(mi.Name, toParams mi, mi.ReturnType)
                m.InvokeCode <- fun args -> Expr.Call(Expr.Coerce(args.Head,ty), mi, args.Tail)
                def.AddMember(m)
        | _ -> ()

The entire provider is implemented in around 100 lines of code, I’d be interested to hear if anybody else finds it useful :)

Source code

The source is available on GitHub: https://github.com/ptrelford/Disinherit