0.47.0

Remove simplebuiltin compiler option

The ponyc option simplebuiltin was never useful to users but had been exposed for testing purposes for Pony developers. We've removed the need for the "simplebuiltin" package for testing and have remove both it and the compiler option.

Technically, this is a breaking change, but no end-users should be impacted.

Fix return checking in behaviours and constructors

Our checks to make sure that the usage of return in behaviours and constructors was overly restrictive. It was checking for any usage of return that had a value including when the return wasn't from the method itself.

For example:

actor Main
  new create(env: Env) =>
    let f = {() => if true then return None end}

Would return an error despite the return being in a lambda and therefore not returning a value from the constructor.

Fix issue that could lead to a muted actor being run

A small logical flaw was discovered in the Pony runtime backpressure system that could lead to an actor that has been muted to prevent it from overloading other actors to be run despite a rule that says muted actors shouldn't be run.

The series of events that need to happen are exceedingly unlikely but we do seem them from time to time in our Arm64 runtime stress tests. In the event that a muted actor was run, if an even more unlikely confluence of events was to occur, then "very bad things" could happen in the Pony runtime where "very bad things" means "we the Pony developers are unable to reason about what might happen".

Remove library mode option from ponyc

From the very early days of the Pony runtime, a "library mode" has been around that allows you to compile a Pony program to a C compatible library that you can then start up using various runtime APIs to do things like initialize the runtime, create actors, send messages and more. We've made extensive changes to the runtime over the years and have no faith that library mode and its related functionality work.

Our lack of faith extends back many years and we've stated as the Pony core team that we don't consider library mode to be supported; until now, we haven't done anything about what "not supported" means.

With this release, library mode has been removed as an option.

Don't allow interfaces to have private methods

When Pony allowed interfaces to have private methods, it was possible to use an interface to break encapsulation for objects and access private methods from outside their enclosing package.

The following code used to be legal Pony code but will now fail with a compiler error:

actor Main
  new create(env: Env) =>
    let x: String ref = "sailor".string()
    let y: Foo = x
    y._set(0, 'f')
    env.out.print("Hello, " + x)

interface Foo
  fun ref _set(i: USize, value: U8): U8

If you were previously using interfaces with private methods in your code, you'll need to switch them to being traits and then use nominal typing on all the implementers.

For example:

interface Foo
  fun ref _bar()

would become:

trait Foo
  fun ref _bar()

And any objects that need to provide Foo would be changed from:

class ProvidesFoo

to

class ProvidesFoo is Foo

We believe that the only impact of this change will primarily be a single interface in the standard library AsioEventNotify and updates that need to be done to deal with it changing from an interface to a trait.

If you are unable to make the changes above, it means that you were taking the encapsulation violation bug we've fixed and will need to rethink your design. If you need assistance with such a redesign, please stop by the Pony Zulip and we'll do what we can to help.

Change builtin/AsioEventNotify from an interface to a trait

The "Don't allow interfaces to have private methods" change that is part of this release required that we change the AsioEventNotify interface to a trait.
If you are one of the few users outside of the standard library to be using the ASIO subsystem directly in your Pony code, you'll need to make an update to
conform to this change.

Where previously you had something like:

class AsioEventReceivingClass
  be _event_notify(event: AsioEventID, flags: U32, arg: U32) =>
    ...

You'll need to switch to using nominal typing rather than structural:

class AsioEventReceivingClass is AsioEventNotify
  be _event_notify(event: AsioEventID, flags: U32, arg: U32) =>
    ...

As far as we know, there are two codebases that will be impacted by this change:

• Lori
• Wallaroo

Fix compiler assertion failure when assigning error to a variable

This release fixes a compiler assertion failure being triggered when one attempted to assign an error expression surrounded by parenthesis to a variable.

Add "nodoc" annotation

The can be used to control the pony compilers documentation generation, any structure that can have a docstring (except packages) can be annotated with \nodoc\ to prevent documentation from being generated.

This replaces a hack that has existed in the documentation generation system for several years to filter out items that were "for testing" by looking for Test and _Test at the beginning of the name as well as providing UnitTest or TestList.

Note that the "should we include this package" hack to filter oupackages called "test" and "builtin_test" still exists for the timbeing until we have further discussion.

[0.47.0] - 2022-02-02

Fixed

• Fix return checking in behaviours and constructors (PR #3971)
• Fix issue that could lead to a muted actor being run (PR #3974)
• Fix loophole that allowed interfaces to be used to violate encapsulation (PR #3973)
• Fix compiler assertion failure when assigning error to a variable (PR #3980)

Added

• Add "nodoc" annotation (PR #3978)

Changed

• Remove simplebuiltin compiler option (PR #3965)
• Remove library mode option from ponyc (PR #3975)
• Change builtin/AsioEventNotify from an interface to a trait (PR #3973)
• Don't allow interfaces to have private methods (PR #3973)
• Remove hack that prevented documentation generation for "test classes" (PR #3978)

0.46.0

Stop creating Centos 8 releases

CentOS 8 has been end-of-lifed and will be receiving no further updates. As per our policy, we will no longer be building regular releases for CentOS 8. Existing releases can still be installed via ponyup, but no additional releases will be done.

Our CentOS 8 support has been replaced by support for Rocky 8.

Hide C header implementation details related to actor pad size.

Previously, in the pony.h header that exposes the "public API" of the Pony runtime, information about the size of an actor struct was published as public information.

This change removes that from the public header into a private header, to hide
implementation details that may be subject to change in future versions of the Pony runtime.

This change does not impact Pony programs - only C programs using the pony.h header to use the Pony runtime in some other way than inside of a Pony program, or to create custom actors written in C.

Change type of Env.root to AmbientAuth

Previously, Env.root currently had the type (AmbientAuth | None) to allow for creation of artificial Env instances without AmbientAuth. Yet, there was no observable usage of this feature. It required extra work to make use of, as one always needs a pattern match or an as expression with a surrounding try. We've changed Env.root to only be AmbientAuth, no longer requiring a pattern match or a try.

To adjust your code to take this breaking change into account, you'd do the following. Where you previously had code like:

    try
      TCPListener(env.root as AmbientAuth, Listener(env.out))
    else
      env.out.print("unable to use the network")
    end

You can now do:

    TCPListener(env.root, Listener(env.out))

The same change can be made if you were pattern matching on the type of env.root.

[0.46.0] - 2022-01-16

Changed

• Stop creating CentOS 8 prebuilt ponyc releases (PR #3955)
• Hide C header implementation details related to actor pad size. (PR #3960)
• Change type of Env.root to AmbientAuth (PR #3962)

0.45.2

Clarify wording for some subtyping errors

The wording of a small number of errors relating to the subtyping of capabilities were improved.
These were previously technically incorrect, or otherwise unnecessarily obtuse.

Fix inability to fully build pony on Raspberry PI 4's with 64-bit Raspbian

Building on 64-bit Raspbian needs the flag -fPIC instead of -fpic which is used by default on Unix builds.

We've added a Makefile flag pic_flag that you can set to either -fpic or -fPIC for both libs and configure steps, e.g. make libs pic_flag=-fPIC and make configure pic_flag=-fPIC. It will default to -fpic if not specified.

Added build instructions for 64-bit Raspbian

We've gotten Pony building on 64-bit Raspbian running on Raspberry Pi 4 model B boards. The installation is a little different than other Linux distributions that you can build Pony on, so we've added instructions specific to 64-bit Raspbian.

0.45.1

Fix underlying time source for Time.nanos() on macOS

Previously, we were using mach_absolute_time on macOS to get the number of ticks since boot, with the assumption that ticks increment at nanosecond intervals. However, as noted by Apple, this assumption is flawed on Apple Silicon, and will also affect any binaries that were built on Intel, as the Rosetta 2 translator will not apply any time conversion.

The recommended replacement to mach_absolute_time is to use clock_gettime_nsec_np with a clock of type CLOCK_UPTIME_RAW.

Fix cli package from mangling option arguments with equal signs

The current command parser in the cli package cuts option arguments of String type at the first equal sign. This release fixes the problem for long options (--option=foo=bar) and for short options such as -O=foo=bar. Short options such as -Ofoo=bar will continue to raise an "ambiguous args" error.

The code below shows the bug, with the option argument being cut short at the first equal sign. The code below prints "foo" instead of the complete value, "foo=bar". The same is true when uses the short version of the option, like -t=foo=bar.

use "cli"

actor Main
  new create(env: Env) =>
    try
      let cs =
        CommandSpec.leaf("simple", "", [
          OptionSpec.string("test" where short' = 't')
        ])?
      
      let args: Array[String] = [
        "ignored"; "--test=foo=bar"
      ]
      let cmdErr = CommandParser(cs).parse(args) as Command
      env.out.print(cmdErr.option("test").string())
    end

[0.45.1] - 2021-12-02

Fixed

• Fix underlying time source for Time.nanos() on macOS (PR #3921)
• Fix cli package from mangling option arguments with equal signs (PR #3925)

0.45.0

Remove options package

Removes the options package, which was deprecated in version 0.26.0 in favor of the cli package.

An example program using the options package is immediately below, while the rewrite with the cli package follows it.

use "options"

actor Main
  let _env: Env
  // Some values we can set via command line options
  var _a_string: String = "default"
  var _a_number: USize = 0
  var _a_unumber: USize = 0
  var _a_float: Float = F64(0.0)

  new create(env: Env) =>
    _env = env
    try
      arguments()?
    end

    _env.out.print("The String is " + _a_string)
    _env.out.print("The Number is " + _a_number.string())
    _env.out.print("The UNumber is " + _a_unumber.string())
    _env.out.print("The Float is " + _a_float.string())

  fun ref arguments() ? =>
    var options = Options(_env.args)

    options
      .add("string", "t", StringArgument)
      .add("number", "i", I64Argument)
      .add("unumber", "u", U64Argument)
      .add("float", "c", F64Argument)

    for option in options do
      match option
      | ("string", let arg: String) => _a_string = arg
      | ("number", let arg: I64) => _a_number = arg.usize()
      | ("unumber", let arg: U64) => _a_unumber = arg.usize()
      | ("float", let arg: F64) => _a_float = arg
      | let err: ParseError => err.report(_env.out) ; usage() ; error
      end
    end

  fun ref usage() =>
    // this exists inside a doc-string to create the docs you are reading
    // in real code, we would use a single string literal for this but
    // docstrings are themselves string literals and you can't put a
    // string literal in a string literal. That would lead to total
    // protonic reversal. In your own code, use a string literal instead
    // of string concatenation for this.
    _env.out.print(
      "program [OPTIONS]\n" +
      "  --string      N   a string argument. Defaults to 'default'.\n" +
      "  --number      N   a number argument. Defaults to 0.\n" +
      "  --unumber     N   a unsigned number argument. Defaults to 0.\n" +
      "  --float       N   a floating point argument. Defaults to 0.0.\n"
      )

use "cli"

actor Main
  new create(env: Env) =>
    let cs =
      try
        CommandSpec.leaf("run", "", [
          OptionSpec.string("string", "String argument"
            where short' = 't', default' = "default")
          OptionSpec.i64("number", "Number argument"
            where short' = 'i', default' = 0)
          OptionSpec.u64("unumber", "Unsigned number argument"
            where short' = 'u', default' = 0)
          OptionSpec.f64("float", "Float argument"
            where short' = 'c', default' = 0.0)
        ], [])? .> add_help()?
      else
        env.exitcode(-1)  // some kind of coding error
        return
      end

    let cmd =
      match CommandParser(cs).parse(env.args, env.vars)
      | let c: Command => c
      | let ch: CommandHelp =>
          ch.print_help(env.out)
          env.exitcode(0)
          return
      | let se: SyntaxError =>
          env.out.print(se.string())
          env.exitcode(1)
          return
      end

    let string = cmd.option("string").string()
    let number = cmd.option("number").i64()
    let unumber = cmd.option("unumber").u64()
    let float = cmd.option("float").f64()

    env.out.print("The String is " + string)
    env.out.print("The Number is " + number.string())
    env.out.print("The UNumber is " + unumber.string())
    env.out.print("The Float is " + float.string())

Fix erratic cycle detector triggering on some Arm systems

Triggering of cycle detector runs was based on an assumption that our "tick" time source would monotonically increase. That is, that the values seen by getting a tick would always increase in value.

This assumption is true as long as we have a hardware source of ticks to use. However, on some Arm systems, the hardware cycle counter isn't available to user code. On these these, we fall back to use clock_gettime as a source of ticks. When clock_gettime is the source of ticks, the ticks are no longer monotonically increasing.

Usage of the cycle detector with the non-monotonically increasing tick sources would cause the cycle detector run very infrequently and somewhat erratically. This was most likely to be seen on hardware like the Raspberry Pi.

Fix non-release build crashes on Arm

We've fixed a cause of "random" crashes that impacted at minimum, debug versions of Pony programs running on 32-bit Arm builds on the Raspberry Pi 4.

It's likely that the crashes impacted debug versions of Pony programs running on all Arm systems, but we don't have enough testing infrastructure to know for sure.

Add Ubuntu 21.04 nightly builds and releases builds

We've added nightly and release builds of ponyc that are built on Ubuntu 21.04. We'll continue supporting them through the end of life of this non-LTS version of Ubuntu.

Fix major source of runtime instability on non-x86 based platforms

We've replaced our existing code for handling the ABA problem when running on Arm CPUs. The implementation we replaced was buggy and resulted in runtime instability including crashes and memory corruption.

Update to LLVM 13.0.0

We've updated the LLVM used to build Pony to 13.0.0.

Fix segfaults with debug builds on 64-bit Arm

Debug builds on 64-bit Arm platforms were segfaulting. The code generated when doing ponyc --debug wouldn't work and would eventually crash. We believe the source to be an LLVM bug but, aren't certain.

We've introduced a work around that fixes the segfault problem, but does some optimization of debug builds for 64-bit Arm platforms. Additional investigation is underway. You can track progress by following issue #3874.

Add Graviton 64-bit Arm CPUs as a supported architecture

We've add continuous integration testing on AWS Graviton instances via CirrusCI. All code changes going forward will be tested on Graviton.

This provides us some fairly good coverage for "64-bit Arm" support in general although various other platforms like the Raspberry Pi 4B and Apple M1 chips are still "best effort" as we don't have any CI for them and we've found them to be somewhat different than Graviton.

Added build instructions for 32-bit Raspbian

We've gotten Pony building on 32-bit Raspbian running on Raspberry Pi 4 model B boards. The installation is a little different than other Linux distributions that you can build Pony on, so we've added instructions specific to 32-bit Raspbian.

Add Apple Silicon as a supported platform

Pony is now supported on Apple Silicon (M1 processors). Our support is "best effort" for now, since we currently lack continuous integration for Apple Silicon. Users on this platform will need to install Pony from source for the time being.

Fixed incorrect version in ponyc nightly builds

The build system facility that allowed us to set arbitrary versions in builds was broken. The end result was nightly builds not having meaningful results when ponyc --version was run.

[0.45.0] - 2021-11-01

Fixed

• Fix erratic cycle detector triggering on some Arm systems (PR #3854)
• Fix non-release build crashes on Arm (PR #3860)
• Fix major source of runtime instability on non-x86 based platforms (PR #3871)
• Fix segfaults with debug mode code on 64-bit Arm (PR #3875)
• Fix incorrect version in nightly ponyc builds (PR #3895)

Added

• Add Ubuntu 21.04 nightly builds and releases builds (PR #3866)
• Add 64-bit Arm (Graviton) as a supported platform (PR #3876)
• Add build instructions for 32-bit Raspbian (PR #3879)
• Add Apple Silicon as a supported platform (PR #3883)

Changed

• Remove options package (PR #3844)
• Update to LLVM 13.0.0 (PR #3837)

0.44.0

Fixed a compile-time crash related to Pony-specific optimizations

Ticket #3784 tracked an issue related the MergeMessageSend optimization pass, which does Pony-specific optimizations within the LLVM optimizer pipeline.

It turned out that this pass was not written to handle the case of being run on a code block that contained sections of code that had already been optimized by this pass, and in such a case it failed an assertion error, crashing the compiler on such a program.

The fix was to disable running the pass on blocks in which we could detect signs of the optimization of that pass already being present.

Programs that were previously compiling okay should not see any difference in behavior or performance - the only programs that could potentially benefit from the skipped optimization were crashing, so there is no regression in their behavior.

Split FilePath construction into two methods

FilePath previously had only one constructor, the default create, which used a union of (AmbientAuth | FilePath). The first half of this union AmbientAuth could never error, while the second FilePath could error. By splitting construction into two methods, we now have a default create constructor which cannot error and a new from constructor which can error. The default create constructor now accepts a new "files" package root authority FileAuth as well as the global root authority AmbientAuth, while the new from constructor uses FilePath.

The result of this change is that three user changes are needed, namely around create, from, and mkdtemp. Any place where previously AmbientAuth was accepted now also accepts FileAuth.

Prior to this change, create could be used with AmbientAuth as in:

let ambient: AmbientAuth = ...
let filepath: FilePath = FilePath(ambient, path)?

After this change, create can be used with AmbientAuth or FileAuth -- note that this can no longer fail:

let ambient: AmbientAuth = ...
let filepath: FilePath = FilePath(ambient, path)

or

let fileauth: FileAuth = ...
let filepath: FilePath = FilePath(fileauth, path)

---

Prior to this change, create could be used with FilePath as in:

let filepath: FilePath = ...
let subpath = FilePath(filepath, path)?

After this change, construction with an existing FilePath must use from:

let filepath: FilePath = ...
let subpath = FilePath.from(filepath, path)?

---

Prior to this change, mkdtemp could be used with AmbientAuth or FilePath as in:

let ambient: AmbientAuth = ...
let tempdir = FilePath.mkdtemp(ambient, prefix)?

or

let filepath: FilePath = ...
let tempdir = FilePath.mkdtemp(filepath, prefix)?

After this change, mkdtemp can also use FileAuth -- note can still fail:

let fileauth: FileAuth = ...
let tempdir = FilePath.mkdtemp(fileauth, prefix)?

[0.44.0] - 2021-09-03

Fixed

• Fix a compile-time crash related to Pony-specific optimizations. (PR #3831)

Changed

• Update FilePath constructors to allow a non-partial way to create a FilePath (PR #3819)

0.43.2

Clean up child process exits on Windows

Fixed the ProcessMonitor class sometimes waiting on an invalid process handle on Windows.

Fixed Windows TCP faulty connection error

Fixed a bug where a TCPConnection could connect to a socket that wasn't listening.

Fixed zombie Windows TCP connection error

Fixed a bug where socket events were sometimes never unsubscribed to which would lead to "zombie" connections that were open but couldn't receive data.

Fixed "oversleeping" on Windows

Previously, we were calling Sleep rather than SleepEx when putting scheduler threads to sleep. This could have caused Windows IO events to be missed.

Fix broken libponyc-standalone.a

When we switched to LLVM 12, we accidentally picked up zlib being required to link against libponyc-standalone.a. That additional dependency makes the standalone library not so standalone.

We've fixed our LLVM configuration so that zlib is no longer needed.

[0.43.2] - 2021-08-28

Fixed

• Clean up child process exits on Windows (PR #3817)
• Cleanup and fixes for Windows sockets (PR #3816)
• Stop standalone libponyc from needing zlib (PR #3827)

0.43.1

Fixed compiler build issues on FreeBSD host

Added relevant include and lib search paths under /usr/local
prefix on FreeBSD, to satisfy build dependencies for Pony compiler.

Add FileMode.u32

Adds a public method on FileMode to get an OS-specific representation of the FileMode as a u32.

Make working with Promise[Promise[B]] chains easier

We've added a new method flatten_next to Promise in order to make working with promises of promises easier.

flatten_next is a companion to next. It operates in an identical fashion except for the type of the fulfilled promise. Whereas next takes a function that returns a type B, flatten_next takes a function that returns Promise[B].

Why is flatten_next valuable given that next could take a B that is of a type like Promise[String]? Let's start with some code to demonstrate the problem that arises when returning Promise[Promise[B]] from next.

Let's say we have a library for accessing the GitHub REST API:

class GitHub
  new create(personal_access_token: String)

  fun get_repo(repo: String): Promise[Repository]

class Repository
  fun get_issue(number: I64): Promise[Issue]

class Issue
  fun title(): String

And we want to use this promise based API to look up the title of an issue. Without flatten_next, we could attempt to do the following using next:

actor Main
  new create(env: Env) =>
    let repo: Promise[Repository] =
      GitHub("my token").get_repo("ponylang/ponyc")

    //
    // do something with the repo once the promise is fulfilled
    // in our case, get the issue
    //

    let issue = Promise[Promise[Issue]] =
      repo.next[Promise[Issue]](FetchIssue~apply(1))

    // once we get the issue, print the title
    issue.next[None](PrintIssueTitle~apply(env.out))

primitive FetchIssue
  fun apply(number: I64, repo: Repository): Promise[Issue] =>
    repo.get_issue(number)

primitive PrintIssueTitle
  fun apply(out: OutStream, issue: Promise[Issue]) =>
    // O NO! We can't print the title
    // We don't have an issue, we have a promise for an issue

Take a look at what happens in the example, when we get to PrintIssueTitle, we can't print anything because we "don't have anything". In order to print the issue title, we need an Issue not a Promise[Issue].

We could solve this by doing something like this:

primitive PrintIssueTitle
  fun apply(out: OutStream, issue: Promise[Issue]) =>
    issue.next[None](ActuallyPrintIssueTitle~apply(out))

primitive ActuallyPrintIssueTitle
  fun apply(out: OutStream, issue: Issue) =>
    out.print(issue.title())

That will work, however, it is kind of awful. When looking at:

    let repo: Promise[Repository] =
      GitHub("my token").get_repo("ponylang/ponyc")
    let issue = Promise[Promise[Issue]] =
      repo.next[Promise[Issue]](FetchIssue~apply(1))
    issue.next[None](PrintIssueTitle~apply(env.out))

it can be hard to follow what is going on. We can only tell what is happening because we gave PrintIssueTitle a very misleading name; it doesn't print an issue title.

flatten_next addresses the problem of "we want the Issue, not the intermediate Promise". flatten_next takes an intermediate promise and unwraps it into the fulfilled type. You get to write your promise chain without having to worry about intermediate promises.

Updated to use flatten_next, our API example becomes:

actor Main
  new create(env: Env) =>
    let repo: Promise[Repository] =
      GitHub("my token").get_repo("ponylang/ponyc")

    let issue = Promise[Issue] =
      repo.flatten_next[Issue](FetchIssue~apply(1))

    issue.next[None](PrintIssueTitle~apply(env.out))

primitive FetchIssue
  fun apply(number: I64, repo: Repository): Promise[Issue] =>
    repo.get_issue(number)

primitive PrintIssueTitle
  fun apply(out: OutStream, issue: Issue) =>
    out.print(issue.title())

Our promise Issue, is no longer a Promise[Promise[Issue]]. By using flatten_next, we have a much more manageable Promise[Issue] instead.

Other than unwrapping promises for you, flatten_next otherwise acts the same as next so all the same rules apply to fulfillment and rejection.

[0.43.1] - 2021-08-03

Fixed

• Fixed Makefile for FreeBSD (PR #3808)

Added

• Add FileMode.u32 (PR #3809)
• Add FileMode.u32 (PR #3810)
• Make working with promises of promises easier (PR #3813)

0.43.0

Add prebuilt ponyc binaries for Rocky Linux 8

Prebuilt nightly versions of ponyc are now available from our Cloudsmith nightlies repo. Release versions will be available in the release repo starting with this release.

CentOS 8 releases were added as we currently support CentOS 8, but it will be discontinued in a few months and Rocky Linux provides a seamless transition path.

If you are a Pony user and are looking for prebuilt releases for your distribution, open an issue and let us know. We'll do our best to add support for any Linux distribution version that is still supported by their creators.

Fix OOM error when running ponyc built with xcode 12.5

Changes in Big Sur and xcode as of 12.5 have lead to an out of memory error with ponyc. If pony's allocator is built with usage of VM_FLAGS_SUPERPAGE_SIZE_ANY on, it will run out of memory if xcode 12.5 was used to build.

VM_FLAGS_SUPERPAGE_SIZE_ANY isn't required on earlier versions. It does however, improve performance when allocating. Usage of VM_FLAGS_SUPERPAGE_SIZE_ANY has been removed as it also doesn't work on newer M1 based machines and thus, is on its way out in general.

Fix API mismatch errors when linking pony programs on MacOS

We have been setting a minimal API version for ponyc that didn't match the LLVM value. This resulted in errors about how the link versions didn't match. The warnings caused no issues running programs, but did lead to confusion amongst new users. They were also annoying to look at all the time.

We did some testing and determined that there's no need to set the value as we can build ponyc and other pony programs on Big Sur and still use on earlier versions of MacOS.

There might be some issues that crop up in the future, but as far as we can tell, for normal ponyc MacOS usage, we dont need to set macosx-version-min.

Fix broken IsPrime standard library feature

Any prime after 1321 wasn't being correctly identified.

Prevent non-opaque structs from being used as behaviour parameters

When a non-opaque object is sent across actors, its type descriptor is used by the garbage collector in order to trace it. Since structs lack a type descriptor, using a val or iso struct as a parameter behaviour could lead to a runtime segfault. This also applies to tuple parameters where at least one element is a non-opaque struct.

This is a breaking change. Existing code will need to wrap struct parameters in classes or structs, or use structs with a tag capability. Where you previously had code like:

struct Foo

actor Main
  new create(env: Env) =>
    inspect(recover Foo end)

  be inspect(f: Foo iso) =>
    // Do something with f

you will now need

struct Foo

class Bar
  let f: Foo = Foo

actor Main
  new create(env: Env) =>
    inspect(recover Bar end)

  be inspect(wrap: Bar iso) =>
    // Do something with wrap.f

When using tuples with struct elements, you don't need to wrap the entire tuple. It is enough to wrap the struct elements.

Update to LLVM 12.0.1

We've updated the LLVM used to build pony to LLVM 12.0.1 and in the process, we've dropped support for 32-bit ARM as supported platform.

We might bring 32-bit Arm back as a supported platform if the Arm fixes we need to do to get ponyc working on M1 also fix the current issues we have with 32-bit Arm with LLVM 12. The errors currently present the same so we assume that adding M1 support will bring 32-bit ARM along with it. If fixing the M1 issues doesn't fix 32-bit Arm issues then we'll have to make a decision about whether we bring back 32-bit Arm support.

[0.43.0] - 2021-07-14

Fixed

• Fix OOM on MacOS when using xcode 12.5 (PR #3793)
• Fix MacOS version mismatch warnings when linking Pony programs (PR #3798)
• Fix the calculation of "is prime" for numbers after 1321. (PR #3799)
• Prevent non-opaque structs from being used as behaviour parameters (PR #3781)

Added

• Add support for prebuilt Rocky Linux versions (PR #3783)

Changed

• Update to LLVM 12.0.1 (PR #3745)

0.42.0

Fix bug where Flags.remove could set flags in addition to unsetting them

Flags.remove when given a flag to remove that wasn't currently present in the set, would turn the flag on.
It should only be turning flags off, not turning them on.

Allow Flags instances to be created with a set bit encoding

Extending Flags.create to (optionally) allow initialization of a Flags
object with the numeric representation populated. This value defaults
to 0 (no flags set).

Don't allow PONYPATH to override standard library

Prior to this change, a library could contain a package called builtin that would override to standard library version. This could be an attack vector. You can still override the standard library location by using the ponyc --paths option.

Any code which relied on the PONYPATH items being before the standard library in the package search path will need to switch to using --paths on the ponyc command line.

[0.42.0] - 2021-07-07

Fixed

• Fix bug where Flags.remove could set flags in addition to unsetting them (PR #3777)

Added

• Allow Flags instances to be created with a set bit encoding (PR #3778)

Changed

• Don't allow PONYPATH to override standard library (PR #3780)