Skip to content

@ponylang-main ponylang-main released this May 1, 2021

Add IsPrime to math package

Quickly determine if a given number is prime using the 6k ± 1 method.

All integers (excluding 2 and 3), can be expressed as (6k + i), where i = -1, 0, 1, 2, 3, or 4. Since 2 divides (6k + 0), (6k + 2), and (6k + 4), while 3 divides (6k + 3) that leaves only (6k - 1) and (6k + 1) for expressing primes

Fix possible memory leak

A possible memory leak in the process package was fixed.

Update supported FreeBSD to FreeBSD 13.0

As of this release, we now do all FreeBSD testing on FreeBSD 13.0 and all ponyc prebuilt packages are built on FreeBSD 13.0. We will make a best effort to not break prior versions of FreeBSD while they are "supported".

[0.40.0] - 2021-05-01

Fixed

  • Use built-in offset argument to cpointer (PR #3741)

Added

  • Add IsPrime checker to math package (PR #3738)

Changed

  • Change supported FreeBSD to 13.0 (PR #3743)
Assets 2

@ponylang-main ponylang-main released this Mar 29, 2021

Fix compiler crash related to type parameter references

Previously, if a method signature in a trait or interface referenced a type
parameter before the type parameter itself was defined, the compiler would
crash. This is now fixed.

Fix early pipe shutdown with Windows' ProcessMonitor

Due to incorrect handling of a Windows pipe return value, the ProcessMonitor would sometimes shut down its pipe connections to external processes before it should have.

Fix literal inference with partial functions

Before this change, code such as 1~add(2) would hit an assertion error when the compiler tried to infer the type of the literal 2. The compiler tries to find the type of the receiver of the function (in this case 1), but before it lacked the ability to do so when using partial functions. In those cases, the compiler would try to look at the type of the ~ token, which is not a valid value literal, and as such it would fail.

[0.39.1] - 2021-03-29

Fixed

  • Fix compiler crash related to type parameter references (PR #3725)
  • Fix early pipe shutdown with Windows ProcessMonitor (PR #3726)
  • Fix literal inference through partial function (PR #3729)
Assets 2

@ponylang-main ponylang-main released this Feb 27, 2021

Fix calculating the number of CPU cores on FreeBSD/DragonFly

The number of CPU cores is used by Pony to limit the number of scheduler threads (--ponymaxthreads) and also used as the default number of scheduler threads.

Previously, sysctl hw.ncpu was incorrectly used to determine the number of CPU cores on FreeBSD and DragonFly. On both systems sysctl hw.ncpu reports the number of logical CPUs (hyperthreads) and NOT the number of physical CPU cores.

This has been fixed to use kern.smp.cores on FreeBSD and hw.cpu_topology_core_ids * hw.cpu_topology_phys_ids on DragonFly to correctly determine the number of physical CPU cores.

This change only affects FreeBSD and DragonFly systems with hardware that support hyperthreading. For instance, on a 4-core system with 2-way HT, previously 8 scheduler threads would be used by default. After this change, the number of scheduler threads on the same system is limited to 4 (one per CPU core).

Change supported FreeBSD version to 12.2

We only maintain support for a single version of FreeBSD at a time due to limited usage of Pony of FreeBSD. We've switched from testing and building releases for 12.1 to 12.2, We would have done this sooner, but we hadn't noticed that 12.2 had been released.

Fix FFI declarations ignoring partial annotation

Previously, the compiler would ignore any ? annotations on FFI declarations, which could result in the generated code lacking any guards for errors, causing the final program to abort at runtime. This change fixes the problem by ensuring that the compiler checks if FFI declarations specify a partial annotation.

Fix building ponyc on DragonFly BSD

DragonFly BSD is lightly used as a ponyc platform. It is also "unsupported" due to lack of CI. Over time, ponyc fell out of being able to be built on DragonFly.

As of this release, you should be able to use ponyc on DragonFly again. However, do to the unsupported nature of the DragonFly port, it might break again in which case, updates from anyone using Pony on DragonFly will be needed.

Create a standalone libponyc on Linux

It's possible to use libponyc from projects other than ponyc. Using the library gives you access to all the various compiler functionality. However, it is hard to use the library because, you need to link in the correct libstdc++, libblake, and LLVM. Figuring out what is the correct version of each is very difficult.

With this change, a new library libponyc-standalone.a will be created as part of the build process.

Applications like the "in pony documentation generator" that we are working on will be able to link to libponyc-standalone and pick up all it's required dependencies.

Windows, BSD, and macOS libraries are not created at this time but can be added as needed in the future.

Fix symbol table patching for default implementations that replaces another method

This release fixes a compiler crash that could happen when a default implementation replaced another method with the same signature. An example of this is when intersecting two interfaces that both have a method with the same signature and the second interface provides a default implementation:

interface A
  fun f(): U32

interface B
  fun f(): U32 =>
    let x: U32 = 42
    x

interface C is (A & B)

In this case, the default implementation was copied to C, but without its symbol table, subsequently resulting in a compiler crash.

Fix tuple related compiler segfaults

Andreas Stührk indentified and fixed the source of two different open issues with tuple handling that caused the pony compiler to crash.

[0.39.0] - 2021-02-27

Fixed

  • Fix calculation of # CPU cores (FreeBSD/DragonFly) (PR #3707)
  • Fix partial FFI declarations ignoring partial annotation (PR #3713)
  • Fix building ponyc on DragonFly BSD (PR #3676)
  • Fix symbol table patching for overriding default methods (PR #3719)
  • Fix tuple related compiler segfaults (PR #3723)

Added

  • Create a standalone libponyc on Linux (PR #3716)

Changed

  • Update supported FreeBSD to 12.2 (PR #3706)
Assets 2

@ponylang-main ponylang-main released this Jan 29, 2021

Fix memory safety problem with Array.from_cpointer

Previously, the from_cpointer method in arrays would trust the user to pass a valid pointer. This created an issue where the user could pass a null pointer using Pointer.create, leading to a situation where memory safety could be violated by trying to access an element of the array. This change makes it safe to pass a null pointer to from_cpointer, which will create a zero-length array.

Fix bad package names in generated documentation

Previously when you used ponyc's documentation generation functions on a code base that used relative imports like use "../foo", the package name in the generated documentation would be incorrect.

[0.38.3] - 2021-01-29

Fixed

  • Fix memory safety problem with Array.from_cpointer (PR #3675)
  • Fix bad package names in generated documentation (PR #3700)
Assets 2

@ponylang-main ponylang-main released this Dec 26, 2020

Fix race conditions that can lead to a segfault

The 0.38.0 release introduced improvement to handling of short-lived actors. However, in the process it also introduced some race condition situations that could lead to segfaults. 0.38.1 introduced a fix that we hoped would address the problems, however, after that release we realized that it didn't fully address the situation. With this change, we've reworked the implementation of the short-lived actor improvements to avoid the trigger for the known race conditions entirely.

Fix compiler crash when an if block ends with an assignment that has no result value

This release fixes a compiler crash that used to occur when certain kinds of assignment expressions that have no logical result value were used as the last expression in an if block, and possibly other control flow constructs as well. Now the compiler makes sure that the code generation for those cases always bears a value, even though the type system guarantees that the value will never be used in such a case. This prevents generating invalid LLVM IR blocks that have no proper terminator instruction.

Fix link errors on macOS Big Sur

With the change from Catalina to Big Sur, Apple moved the location of the System library, which broke the linking phase of the compiler. This change fixes the problem by specifying the absolute path of the System library.

Fix unhandled null pointer that can lead to a segfault

Previously, the os_socket_listen and os_socket_connect internal functions would assume that calls to os_addrinfo_intern would never fail. The os_addrinfo_intern function returns a null pointer on failure, which could result in the callers attempting to free an invalid pointer, and causing a segfault. This change adds error handling on the socket functions, which fixes the problem.

[0.38.2] - 2020-12-26

Fixed

  • Fix race conditions that can lead to a segfault (PR #3667)
  • Fix compiler crash when an if block ends with an assignment that has no result value. (PR #3670)
  • Fix link errors on macOS Big Sur (PR #3686)
  • Fix unhandled null pointer returning from os_addrinfo_intern (PR #3687)
Assets 2

@ponylang-main ponylang-main released this Sep 26, 2020

Fix race condition that can result in a segfault

We recently introduced some improvements to the handling of garbage collection for short-lived actors when the cycle detector is running. In the process, we introduced a race condition in the runtime that could result in an actor being garbage collected twice which if it were to occur, would result in a crashing program.

[0.38.1] - 2020-09-26

Fixed

  • Fix race condition in cycle detector block sent handling (PR #3666)
Assets 2

@ponylang-main ponylang-main released this Sep 24, 2020

Add prebuilt ponyc binaries for CentOS 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 at the request of Damon Kwok. 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 building libs with Visual Studio 16.7

Visual Studio 16.7 introduced a change in C++20 compatibility that breaks building LLVM on Windows (#3634). We've added a patch for LLVM that fixes the issue.

Add prebuilt ponyc binaries for Ubuntu 20.04

We've added prebuilt ponyc binaries specifically made to work on Ubuntu 20.04. At the time of this change, our generic glibc binaries are built on Ubuntu 20.04 and guaranteed to work on it. However, at some point in the future, the generic glibc version will change to another distro and break Ubuntu 20.04. With explicit Ubuntu 20.04 builds, they are guaranteed to work until we drop support for 20.04 when Canonical does the same.

You can opt into using the Ubuntu binaries when using ponyup by running:

ponyup default ubuntu20.04

Fix missing Makefile lines to re-enable multiple use= options

When implementing the CMake build system, I missed copying a couple of lines from the old Makefile that meant that you could only specify one use= option when doing make configure on Posix. This change restores those lines, so you can specify multiple options for use, e.g. make configure use=memtrack_messages,address_sanitizer.

Make Range.next partial

Range.next used to return the final index over and over when you reached the end. It was decided that this was a confusing and error prone API.

Range.next is now partial and will return error when you try to iterate past the end of the range.

Where you previously had code like:

let r = Range(0,5)
let a = r.next()

you now need (or similar based on your usage of Range.next

try
  let r = Range(0,5)
  let a = r.next()?
end

Fix function calls in consume expressions

Function calls are not allowed in consume expressions. However, if the expression being consumed is a field access expression, whose LHS happens to be a function call,
the compiler fails after hitting an assertion.

For instance the following results in a compilation failure

    let a = "I am a string"
    let x:C iso! = consume a.chop(1)

but the following results in a compiler crash with an assertion failure

    let a = "I am a string"
    let x:C iso! = consume a.chop(1)._1

The fix ensures that both the scenarios are handled gracefully.

Speed up cycle detector reaping some actors

When an actor is done running, we now do a check similar to the check we do for when --ponynoblock is on:

  • Check to see if the actor's message queue is empty
  • Check to see if it has a reference count of 0

If both are true, then the actor can be deleted. When --ponynoblock is used, this is done immediately. It can't be done immediately when the cycle detector is in use because, it might have references to the actor in question.

In order to safely cleanup and reap actors, the cycle detector must be the one to do the reaping. This would eventually be done without this change. However, it is possible to write programs where the speed at which the cycle detectors protocol will operate is unable to keep up with the speed at which new "one shot" actors are created.

Here's an example of such a program:

actor Main
  new create(e: Env) =>
    Spawner.run()

actor Spawner
  var _living_children: U64 = 0

  new create() =>
    None

  be run() =>
    _living_children = _living_children + 1
    Spawnee(this).run()

  be collect() =>
    _living_children = _living_children - 1
    run()

actor Spawnee
  let _parent: Spawner

  new create(parent: Spawner) =>
    _parent = parent

  be run() =>
    _parent.collect()

Without this patch, that program will have large amount of memory growth and eventually, run out of memory. With the patch, Spawnee actors will be reaped much more quickly and stable memory growth can be achieved.

This is not a complete solution to the problem as issue #1007 is still a problem due to reasons I outlined at #1007 (comment).

It should also be noted that in the process of developing this patch, we discovered a use after free race condition in the runtime mpmcq implementation. That race condition can and will result in segfaults when running the above example program. There's no issue opened yet for that problem, but one will be coming.

Handling compiler crashes in some consume expressions

Previously an expression of the form consume (consume variable).field resulted in the compiler crashing down with an assertion failure. With this fix, we get a friendly error message pointing to the erroneous line.

Likewise, a valid assignment of the form (consume f).b = recover Bar end resulted in a compiler crash. With the fix, the compiler successfuly type checks the assignment and ensures that f is consumed.

Fix soundness problem with Array.chop

Previously, the chop method on arrays could be used for any element type,
and return two isolated halves. While this is fine for sendable data,
ref elements could have shared references between elements which could
violate this isolation and make the method unsound. This change now
requires that the argument is sendable to call the method.

This is a breaking change. Because the array itself is isolated,
a usage that is genuinely sound can likely be fixed by ensuring
that the element type is iso instead of ref or trn, or val
instead of box, and recovering when elements are constructed.

Allow for building on DragonFlyBSD again

When the ponyc build system was switched from make to cmake, the ability to build on DragonFlyBSD was inadvertenyly removed. The build system has been updated so that ponyc can be built again on DragonFly.

Improvement to garbage collection for short-lived actors

We have a few example programs that create a large number of short-lived actors that can exhibit runaway memory growth. This update greatly reduces the memory growth or potentially reduce it to be stable.

The primary change here is to use some static analysis at compilation time to determine if an actor is "an orphan". That is, upon creation, has no actors (including it's creator) with references to it.

In order to support the concept of an "orphan actor", additional changes had to be made to the cycle detector protocol and how other actors interact with it. There are two primary things we can do with an orphan actor to improve the rate of garbage collection when the cycle detector is running.

When the cycle detector is running actors are collected by the cycle detector when they have no other actors referring to them and can't receive any new messages or are in a cycle that can't receive additional messages.

The examples listed in this PR all had problematic memory usage because, actors were created at a rate that overwhelmed the cycle detector and caused large amount of messages to it to back up and sit in its queue waiting to be processed.

This update addresses the "too many messages" problem by making the following actor GC rule changes for orphan actors. Note, all these rules are when the cycle detector is running.

  • when an actor finishes being run by a scheduler thread "locally delete" it if:

    • no other actors hold a reference to the actor
    • the cycle detector isn't holding a reference to the actor
    • its queue is empty

    "locally deleting" follows the same message free protocol used when the cycle detector isn't running.

  • when an actor finishes being run by a scheduler thread, preemptively inform the
    cycle detector that we are blocked if:

    • no other actors hold a reference to the actor
    • the cycle detector is holding a reference to the actor
    • its queue is empty

    by preemptively informing the cycle detector that we are blocked, the cycle detector can delete the actor more quickly. This "preemptively" notify change was introduced in #3649.

In order to support these changes, additional cycle detector protocol changes were made. Previously, every actor upon creation informed the cycle detector of its existence. If we want to allow for local deleting, then this won't work. Every actor was known by the cycle detector. All concept of "actor created" messages have been removed by this change. Instead, actors have a flag FLAG_CD_CONTACTED that is set if the actor has ever sent a message to the cycle detector. Once the flag is set, we know that locally deleting the actor is unsafe and we can fall back on the slower preemptively inform strategy.

The cycle detector works by periodically sending messages to all actors it knows about and asking them if they are currently blocked as the first step in its "path to actor garbage collection" protocol. As actors no longer inform the cycle detector of their existence on creation, the cycle detector needs a new way to discover actors.

The first time an actor becomes logically blocked, it sets itself as blocked and notifies the cycle detector of its existence and that it is blocked. This is done by:

  • setting the actor as blocked
  • sending an "i'm blocked" message to the cycle detector
  • setting FLAG_CD_CONTACTED on the actor

The overall effect of these changes is:

  • The rate of garbage collection for short-lived actors is improved.
  • Fewer cycle detector related messages are generated.

It should be noted that if an actor is incorrectly identified by the compiler as being an orphan when it is in fact not, the end result would be a segfault. During development of this feature, it was discovered that the following code from the Promise select test would segfault:

let pb = Promise[String] .> next[None]({(s) => h.complete_action(s) })

The issue was that .> wasn't being correctly handled by the is_result_needed logic in expr.c. It is possibly that other logic within the function is faulty and if segfaults are see after this change that didn't exist prior to it, then incorrectly identifying an actor as an orphan might be the culprit.

Prior to these change, examples such as the one from issue #1007 (listed later) would be unable to be collected due to an edge-case in the cycle detector and the runtime garbage collection algorithms.

Issue #1007 was opened with the following code having explosive memory growth:

primitive N fun apply(): U64 => 2_000_000_000

actor Test
  new create(n: U64) =>
    if n == 0 then return end
    Test(n - 1)

actor Main
  new create(env: Env) =>
    Test(N())

A previous PR #3649 partially addressed some memory growth issues by adding the "preemptively informing" that detailed earlier. The example above from #1007 wasn't addressed by #3649 because the key to #3649 was that when done running its behaviors, an actor can see if it has no additional messages AND no references to itself and can then tell the cycle detector to skip parts of the CD protocol and garbage collect sooner. #1007 requires the "local delete" functionality from this change whereas #3649 only provided "pre-emptive informing".

The addition of "local delete" allows for the cycle detector to keep up with many cases of generating large amounts of "orphaned" actors. The from #1007 above wasn't addressed by #3649 because of an implementation detail in the ORCA garbage collection protocol; at the time that an instance of Test is done running its create behavior, it doesn't have a reference count of 0. It has a reference count of 256. Not because there are 256 references but because, when an actor is created puts a "fake value" in the rc value such that an actor isn't garbage collected prematurely. The value will be set to the correct value once the actor that created it is first traced and will be subsequently updated correctly per ORCA going forward.

However, at the time that an instance of Test is finished running its create, that information isn't available. It would be incorrect to say "if rc is 256, I'm blocked and you can gc me". 256 is a perfectly reasonable value for an rc to be in normal usage.

This isn't a problem with the changes in this PR as the compiler detects that each instance of Test will be an orphan and immediately sets its rc to 0. This allows it to be garbage collected as the instance's message queue is empty so long as it's rc remains 0.

Any changes in the future to address lingering issues with creating large numbers of orphaned actors should also be tested with the following examples. Each exercises a different type of pattern that could lead to memory growth or incorrect execution.

Example 2 features reasonably stable memory usage that I have seen from time-to-time, increase rapidly. It should be noted that such an increase is rather infrequent but suggests there are additional problems in the cycle-detector. I suspect said problem is a periodic burst of additional messages to the cycle-detector from actors that can be garbage collected, but I haven't investigated further.

actor Main
  new create(e: Env) =>
    Spawner.run()

actor Spawner
  var _living_children: U64 = 0

  new create() =>
    None

  be run() =>
    _living_children = _living_children + 1
    Spawnee(this).run()

  be collect() =>
    _living_children = _living_children - 1
    run()

actor Spawnee
  let _parent: Spawner

  new create(parent: Spawner) =>
    _parent = parent

  be run() =>
    _parent.collect()

Example 3 has stable memory growth and given that it won't result in any messages being sent to the cycle detector as we have determined at compile-time that the Foo actor instances are orphaned.

actor Main
  var n: U64 = 2_000_000_000

  new create(e: Env) =>
    run()

  be run() =>
    while(n > 0 ) do
      Foo(n)
      n = n - 1
      if ((n % 1_000) == 0) then
        run()
        break
      end
     end

actor Foo
  new create(n: U64) =>
    if ((n % 1_000_000) == 0) then
      @printf[I32]("%ld\n".cstring(), n)
    end

    None

Example 4 has the same characteristics as example 3 with the code as of this change. However, it did exhibit different behavior prior to this change being fully completed and appears to be a good test candidate for any future changes.

actor Main
  var n: U64 = 2_000_000_000

  new create(e: Env) =>
    run()

  be run() =>
    while(n > 0 ) do
      Foo(n)
      n = n - 1
      if ((n % 1_000_000) == 0) then
        @printf[I32]("%ld\n".cstring(), n)
      end
      if ((n % 1_000) == 0) then
        run()
        break
      end
     end

actor Foo
  new create(n: U64) =>
    None

Finally, for anyone who works on improving this in the future, here's an additional test program beyond ones that already exist elsewhere for testing pony programs. This program will create a large number of actors that are orphaned but then send themselves to another actor. This should increase their rc count and keep them from being garbage collected. If the program segfaults, then something has gone wrong and the logic related to orphan actors has been broken. The example currently passes as of this change.

use "collections"

actor Holder
  let _holding: SetIs[ManyOfMe] = _holding.create()

  new create() =>
    None

  be hold(a: ManyOfMe) =>
    _holding.set(a)

  be ping() =>
    var c: U64 = 1_000
    for h in _holding.values() do
      if c > 0 then
        h.ping()
        c = c - 1
      end
    end

actor ManyOfMe
  new create(h: Holder) =>
    h.hold(this)

  be ping() =>
    None

actor Main
  var n: U64 = 500_000
  let holder: Holder

  new create(env: Env) =>
    holder = Holder
    run()

  be run() =>
    while(n > 0 ) do
      ManyOfMe(holder)
      n = n - 1
      if ((n % 1_000) == 0) then
        @printf[I32]("%ld\n".cstring(), n)
        run()
        holder.ping()
        break
      end
     end

[0.38.0] - 2020-09-24

Fixed

  • Fix build failure under GCC 10.2 (PR #3630)
  • Fix building libs with Visual Studio 16.7 (PR #3635)
  • Fix missing Makefile lines to re-enable multiple use= options (PR #3637)
  • Consistent handling of function calls in consume expressions (PR #3647)
  • Speed up cycle detector reaping some actors (PR #3649)
  • Prevent compiler crashes on certain consume expressions (PR #3650)
  • Fix soundness problem with Array.chop (PR #3657)
  • Allow for building on DragonFlyBSD again (PR #3654)

Added

  • Add prebuilt ponyc binaries for CentOS 8 (PR #3629)
  • Add prebuilt ponyc binaries for Ubuntu 20.04 (PR #3632)
  • Improvements to garbage collection of short-lived actors (PR #3653)

Changed

Assets 2

@ponylang-main ponylang-main released this Aug 28, 2020

Fix unsound return types being allowed for autorecover

The existing autorecover code was checking whether it was safe to write to the recovery cap, regardless of whether it was an argument. That's correct for arguments, but for result types we need to ensure that it's safe to extract.

Safety to extract is derived from Steed's extracting table: a type is safe to extract if results in itself under extracting viewpoint adaptation. Thus it is unsound to extract trn from trn, but it is sound to extract box.

Revert RFC 67

The original intent behind RFC0067 was to make it easy to add a prefix with the
log level for any given log message. However, there is a logic bug in the
implementation; the log level prefix added to messages in LogFormatter would
always be the log level specified in Logger.create(), not the log level desired
at specific call sites. This would lead to misleading log messages where the log
level prefix doesn't match the severity of the log message, such as "FINE:
Critical error. Shutting down".

It would be better if these changes were reverted so a more thought-out solution
could be implemented in the future.

Always allow field access for objects defined inside a recover block

Some field accesses were incorrectly being rejected inside recover blocks. This fix allows all nested field accesses on variables which were defined inside the recover block, like the examples below:

recover
   let x = ...
   let y = x.y
   x.y = Foo
   x.y.z = y.z
end

[0.37.0] - 2020-08-28

Fixed

  • Fix unsound return types being allowed for autorecover (PR #3595)
  • Fix compile error with GCC 8.3 (PR #3618)
  • Always allow field access for objects defined inside a recover block (PR #3606)

Changed

  • Update to basing musl images off of Alpine 3.12 (PR #3609)
  • Revert "Implement RFC0067" (PR #3619)
Assets 2

@ponylang-main ponylang-main released this Jul 31, 2020

Pony 0.36.0 is here. We recommend upgrading as soon as possible as it fixes a soundness hole in the type system. Thanks @jasoncarr0!

In addition, 0.36.0 features a few improvements including a small breaking change to the standard library.

Thank you to everyone who contributing to this release, be it by committing code, triaging issues, participating in the RFC process, or otherwise being an awesome member of the Pony community. We see you and we appreciate you. Keep being you and kicking ass.

0.36.0 can be downloaded from Cloudsmith or updated using ponyup. See our installation instructions for more details.

Here are some highlights from this release:

Change trn->trn to box to fix a soundness hole

This change patches a soundness hole in the Pony type system where the viewpoint adaptaion trn->trn is erroneously allowed to be extracted as a trn.

Until we implement George Steed's improved viewpoint adaptation rules, we will be using his non-extracting viewpoint adaptation resulting in box.

This will only break existing Pony code that relies on the viewpoint adaptation trn->trn being equivalent to trn rather than box. In most cases, the trn field of a trn object may be refactored to have the iso capability and fulfill the same requirements.

Force removing read-only files on Windows with FilePath.remove()

FilePath.remove was broken in some cases on Windows. The underlying usage of the C function _unlink() cannot remove a file if it is read-only. This change calls _chmod(..., _S_IWrite) on files that are about to be removed so as to make sure they are removable.

Fix with expressions using tuple destructuring

Prior to this change, a with expression like the following caused the compiler to abort:

with (a, b) = some_tuple do
   error
end

Add LogLevel as argument to LogFormatter

This is a breaking change to the logger package. The log level used by a logger is now available for use when formatting log messages. This will be helpful in replacing the custom log facilities in Corral with the logger in the Pony standard library.

This requires a small change to implementations of the LogFormatter interface:

Before:

primitive MyLogFormatter is LogFormatter
  fun apply(msg: String) => ...

After:

primitive MyLogFormatter is LogFormatter
  fun apply(lvl: LogLevel, msg: String) => ...

RFC 66: Iter maybe

Itertools now provides an API for working with "optional" types (T | None) through an iterator that yields zero or one value. An Iterator[T] can be constructed from a value x: (T | None) using let iter = Iter[T].maybe(x). Then calling iter.next_or(default) will return x, if it is of type T, or default if x is None. For example:

let x: (U64 | None) = 42
match x
| let n: U64 => n.string()
| None => "?"
end

Now can be expressed as:

Iter[U64].maybe(x).map[String]({(n) => n.string() }).next_or("?").string()

[0.36.0] - 2020-07-31

Fixed

  • Compile fix for the latest MSVC compiler (MSVC 19.26.28806.0, from Visual Studio 16.6.2) (PR #3576)
  • Fix with expressions using tuple destructuring. (PR #3586)
  • Fix typeparam check endless recursion (PR #3589)
  • Force removing read-only files on Windows with FilePath.remove() (PR #3588)

Added

  • Added vs2019 preview support for building ponyc (PR #3587)
  • Implement RFC 66: Iter maybe (PR #3603)

Changed

  • Change trn->trn to box to fix a soundness hole (PR #3591)
  • Add LogLevel as argument to LogFormatter (PR #3597)
Assets 2

@ponylang-main ponylang-main released this May 13, 2020

Pony 0.35.1 is a bug fix release. If you are using Pony 0.35.0 on Windows, you should update as soon as possible. Everyone else can skip this release.

Fix incorrect Windows process waiting

Pony 0.35.0 introduced a bug in the ProcessMonitor on Windows. The issue is fixed thanks to this change.

[0.35.1] - 2020-05-13

Fixed

  • Fix incorrect Windows process waiting (PR #3559)

Changed

Assets 2