Table of Contents

Overture Development Status Update Joey Coleman — 21 June 2014

1 Current State/What's happened since the 11th Overture Workshop

1.1 6 releases: 2.0.0 through 2.0.8, 2.1.0

1.1.1 04Dec/31Jan/10Mar/01Apr/20May/13Jun

1.1.2 Average around 1.5 months between releases

1.1.3 New version 2.x features

  1. Eclipse 4.2 base
  2. ASTv2 integration
  3. New AST-based pog
  4. New code generation module
  5. ProB use
  6. Smaller interface improvements (quickfixes, etc) (probably)

1.2 GitHub migration

1.2.1 Started trialling May 2012

1.2.2 Really started transition October 2013

1.2.3 Issue tracker 21 Nov 2013 (the day I generated 1000+ emails…)

1.2.4 Better integration between issues, code, etc

1.2.5 Easier to work with — we're actually using this

1.3 Two buildservers + Travis-CI

1.3.1 Briefly: experimental OS X-based VM (machine was overprovisioned; system performance sucked)

1.3.2 Now: new beefy Linux-based VM at overture.au.dk

1.3.3 Travis-CI — lightweight, live feedback on buildstatus of all commits

  1. No extra configuration on the buildserver
  2. (still a bit buggy, due to build complexity)

1.4 New website

1.4.1 Shinier!

1.4.2 GitHub hosted, static site — essentially zero attack surface aside from GitHub itself

1.4.3 More flexible than the old

1.4.4 Has a issue tracker for website bugs!

  1. Still need to link it on the site

1.4.5 Rewriting (slowly) to sound less like an academic paper

1.4.6 Download numbers (somebody is downloading, at least)

2 Things at the top of my mind

(Everything here is a request for comments)

2.1 File release hosting

2.1.1 GitHub "Releases" used for the standalone files

2.1.2 We still use SourceForge.net for (some of) stuff

  1. To be phased out
  2. Standalone files are posted
  3. Eclipse update site posted

2.1.3 Eclipse update site

  1. No good public+free solution
  2. Will soon use the AU buildserver (temporarily?)

2.2 Build procedure

2.2.1 all in maven

2.2.2 no doc yet

2.2.3 developement branch should always build

2.3 Release procedure

2.3.1 Release procedure documentation incomplete

  1. But some exists

2.3.2 There are many little tasks, distributed everywhere

2.3.3 Next release will be done by Kenneth

  1. I will sit beside and document what's missing

2.3.4 Native installers

  1. Value of this? (unzipping files isn't that difficult)
  2. Windows: Not a huge effort, just not prioritised
  3. OS X: configuration wrestling with tycho/maven
  4. Linux: zip is the only real option (or tar.gz)

2.4 Wiki migration(s)

2.4.1 Backed by a git repository

2.4.2 Easier to keep "clean"

  1. Dead content is removed by just deleting files

2.4.3 Development wiki already on GitHub

  1. i.e. the one we actually use (AU devs, at least)

2.4.4 General wiki currently on an old IHA host

  1. Should be moved; I'd like to put it on GitHub
  2. Test migration soon
  3. Cleanup in the process

2.5 GitHub — issue reporting

2.5.1 Limited file attachments to bug reports

  1. Code can be inlined between ``` or ~
  2. Images may be attached
  3. No real possibility for anything else

2.5.2 Encourages reporters to make minimal examples

2.5.3 Small examples make bugs easier to find

  1. Hidden advantage?

2.5.4 We actively use the GitHub Issues tools

  1. Stark contrast against the sf.net bug tracker

2.6 CSK tests

2.6.1 We should have these under version control somewhere

  1. I will set up a private AU repository

2.6.2 Occasional small changes (recently from Nick in bug #304)

3 Reaction to Kiniry

3.1 His slides

3.1.1 adoption why?

  1. solves new, real problem
  2. community
  3. best-in-class
  4. artifacts

3.1.2 adoption context

  1. teaching (student's interest) > artifacts for instruction > robustness > community
  2. research: impact > bootstrapping > community
  3. commercial: paying > future opportunities > community

3.1.3 noted

  1. strengths: history, age, foundations, community, artifacts
  2. neutral: size, communication, artifacts, quality, source, motivation, uniqueness, momentum
  3. weaknesses: nationality, history, age, foundations, impact, wealth, influence, memes

3.1.4 Recommendations: age, impact, influence, nationality, memes

3.2 What's happened to address those recommendations

3.2.1 I've not done anything to address these directly, to my amusement

3.2.2 Memes — if you take GitHub, StackOverflow to be a meme

3.2.3 Eclipse?

  1. You'll note I use Emacs
  2. Can we do better? and,
  3. We claim a strong border between core/ and ide/

3.3 Foundational effort

3.3.1 The move the GitHub aims (partially) to reduce friction

  1. For curious onlookers, it's now easy to look at and search the code
  2. For potential developers, GitHub directly supports forking and contribution mechanisms, without requiring permission

3.3.2 Website update is intended to make the project look live (a site design that visually dated us to 2002 wasn't helping)

3.3.3 StackOverflow tag

3.4 Awkward niche (devil's advocate)

3.4.1 Kiniry's "prove that VDM is applicable"

3.4.2 Overture doesn't (yet) support the refinement/reificiation chains that are so popular on paper

  1. POG-TP would help mitigate this

3.4.3 Overture doesn't do the strong inferential typechecking seen in FP Langs (union types are no help!)

3.4.4 Overture/VDM is not a great language to implement in

3.4.5 What an awkward niche!

  1. Is there a good story for all of our tradeoffs?

3.4.6 What's our compelling advantage?

Author: Joey Coleman

Created: 2015-02-06 Fri 14:17

Emacs 24.4.1 (Org mode 8.2.10)