v0.9.10

Libtask v0.9.10

Diff since v0.9.9

Fix a bug introduced in 0.9.9 that made certain phi nodes with Union types fail a type assertion.

Merged pull requests:

• Fix #207 (#209) (@mhauru)

Closed issues:

• Libtask v0.9.9 breaks Union types (#207)

v0.9.9

Libtask v0.9.9

Diff since v0.9.8

Remove manual opaque closure optimisation functions in favour of setting the world age and letting the compiler do more work for us, and providing it with some more type information. This changes no functionality, and shouldn't change performance either, but simplifies code.

Merged pull requests:

• Use set_valid_worlds! instead of manual optimisation (#205) (@mhauru)

v0.9.8

Libtask v0.9.8

Diff since v0.9.7

Enables built docs for the current release version of Libtask.

Merged pull requests:

• Close triple backticks in @might_produce docstring + fix docs CI (#206) (@penelopeysm)

Closed issues:

• Turing.jl model errors with "basic block does not dominate" (#200)

v0.9.7

Libtask v0.9.7

Diff since v0.9.6

Fix a concurrency bug, where Libtask would sometimes crash with a "Multiple concurrent writes to Dict detected!" error when TapedTasks were being executed concurrently.

Merged pull requests:

• Fix concurrenty issue with global MC cache (#203) (@mhauru)

Closed issues:

• Writing to mc_cache is not thread-safe (#202)

v0.9.6

Libtask v0.9.6

Diff since v0.9.5

Add support for Julia v1.12.

Merged pull requests:

• Support for Julia v1.12 (#196) (@mhauru)

Closed issues:

• Supporting functions with keyword arguments (#197)

v0.9.5

Libtask v0.9.5

Diff since v0.9.4

Added a new Libtask.@might_produce macro, which generates a superset of the Libtask.might_produce methods needed for a function f that might contain a call to Libtask.produce. For example, for a function

function f(x::Int, y::Int)
    produce(x + y)
end

instead of writing

Libtask.might_produce(::Type{<:Tuple{typeof(f),Int,Int}}) = true

you can just write

Libtask.@might_produce(f)

The main benefit of this is that it applies to functions with multiple methods and keyword arguments. The drawback is performance: marking all methods of f as produceable may lead to performance degradation if there are some methods of f which do not need to be thus marked. In such cases, you should use the might_produce function directly.

Merged pull requests:

• Add @might_produce macro (#198) (@penelopeysm)

v0.9.4

Libtask v0.9.4

Diff since v0.9.3

Merged pull requests:

• Fix predecessor blocks on 1.11 (#195) (@mhauru)

v0.9.3

Libtask v0.9.3

Diff since v0.9.2

Merged pull requests:

• Fix using return value of produce (#191) (@mhauru)
• Fix a bug with indirect produce calls in a loop (#192) (@mhauru)

Closed issues:

• access to undefined reference (#190)

v0.9.2

Libtask v0.9.2

Diff since v0.9.1

Merged pull requests:

• Issue #185 (#187) (@mhauru)
• Fix varargs calls (#188) (@mhauru)

Closed issues:

• produce not being hit with type unstable variable (#185)
• DynamicCallable issue with varargs (#186)

v0.9.1

Libtask v0.9.1

Diff since v0.9.0

Merged pull requests:

• Mark Libtask.might_produce public. (#182) (@yebai)