EIP: https://github.com/extism/proposals/pull/8
This PR makes minor breaking changes to several SDKs, but not to runtime
C API. The threadsafety updates in the Rust SDK are kind of specific to
Rust, I'm not sure if it makes sense to add the locks to all the other
SDKs at this point. For the most part the `Context` and `Plugin` types
in the SDKs should be safe to use protected by a mutex but they aren't
inherently threadsafe. That kind of locking should probably be done by
the user.
- Runtime
- improve thread safety
- reinstantiates less
- fixes a potential resource exhaustion bug from re-instantiating using
the same store too many times
- Rust SDK
- adds `Send` and `Sync` implementations for `Context`
- adds test sharing a context between threads
- adds `Plugin::call_map` to call a plugin and handle the output with
the lock held
- adds testing sharing an `Arc<Mutex<Plugin>>` between threads
- adds `Plugin::create` and `Plugin::create_from_manifest` to create a
plugin without a `Context`
- Python
- BREAKING
- changes `Plugin` constructor to take `context` as an optional named
argument, to update use `Plugin(data, context=context)` instead
- Ruby
- BREAKING
- changes `Plugin` constructor to take `context` as an optional named
argument, to update use `Plugin.new(data, context=context)` instead
- Go
- adds `NewPlugin` and `NewPluginFromManifest` functions
- Node
- BREAKING
- changes `Plugin` constructor to take `context` as an optional named
argument, to update use `new Plugin(data, wasi, config, host, context)`
instead of `new Plugin(context, data, wasi, functions, config)` (most
people are probably using `context.plugin` instead of the Plugin
constructor anyway)
- OCaml
- BREAKING
- changes `Plugin.create` and `Plugin.of_manifest` to take `context` as
an optional named argument, to update `Plugin.create ~context data` and
`Plugin.of_manifest ~context data` instead
- Haskell
- adds `createPlugin` and `createPluginFromManifest` functions
- Elixir
- adds `Plugin.new` to make a plugin without going through
`Context.new_plugin`
- Java
- adds new `Plugin` constructors without a `Context` argument
- C++
- BREAKING
- Updates `Plugin` constructor to take an optional context as the last
argument, instead of requiring it to be the first argument
- Use `Plugin(wasm, wasi, functions, ctx)` instead of `Plugin(ctx, wasm,
wasi, functions)`
- Zig
- Adds `Plugin.create` and `Plugin.createWithManifest` to create plugins
in their own context.
---------
Co-authored-by: zach <zach@dylib.so>
Co-authored-by: Benjamin Eckel <bhelx@simst.im>
There are some breaking changes:
- Plugin.init now requires an allocator and functions slice
- Plugin.initFromManifest now requires a functions slice
- Plugin struct removed in favor of using the file as struct
- from @nilslice: https://zig.news/gowind/zig-files-are-structs-288j
(good reference!)
---------
Co-authored-by: Steve Manuel <steve@dylib.so>
Can't quite figure out what is going on. Jest cannot resolves our code
fine but can't seem to resolve the NPM module:
```
FAIL src/index.test.ts
● Test suite failed to run
Cannot find module '@bjorn3/browser_wasi_shim' from 'src/plugin.ts'
Require stack:
src/plugin.ts
src/context.ts
src/index.ts
src/index.test.ts
2 | import { PluginConfig } from './manifest';
3 | //@ts-ignore TODO add types to this library
> 4 | import { WASI, File } from "@bjorn3/browser_wasi_shim";
| ^
5 |
6 | export default class ExtismPlugin {
7 | moduleData: ArrayBuffer;
at Resolver._throwModNotFoundError (node_modules/jest-resolve/build/resolver.js:425:11)
at Object.<anonymous> (src/plugin.ts:4:1)
at Object.<anonymous> (src/context.ts:2:1)
at Object.<anonymous> (src/index.ts:1:1)
at Object.<anonymous> (src/index.test.ts:1:1)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 0.916 s
Ran all test suites.
```
For now let's comment it out since it's not providing value anyway.
Hi,
We want to use Extism on our project
[Otoroshi](https://github.com/MAIF/otoroshi) but we need to run it on
jdk11
This pull request makes everything run smoothly on jdk11
If you have any suggestion about this pull request, i'm open to it
Thanks for your time
Takes new version of the wasi shim and ensures that both CJS and ESM
distributions can be built.
Already published as 0.2.2
Co-authored-by: Steve Manuel <steve@dylib.so>
I am working on a .NET host for extism. My plan is to do the following:
- [x] Implement a proof of concept to make sure things are possible
- [x] Write docs for the C# API so that the users get a nice IDE
experience
- [x] Create a github action to publish the NuGet packages
- [x] Edit `ci.yml` to include .NET Sdk
- [x] Create `release-dotnet.yml` to release `Extism.Sdk` nuget package
- [x] Maybe Create `release-dotnet-native.yml` to release
`Extism.runtime.win` nuget package
- [x] Test on Linux (Help needed)
- [x] Test on Mac (Help needed)
- [x] Expose all of the Extism functions
- [x] Write automated tests
- [x] ~Edit README show that the there is a .NET SDK~. Probably we
should not do this until we have a docs page.
- [x] ~Use the `Extism.runtime.win-x64` package in the sample project~
Out of scope for this PR:
- Json Serialization/Desererialization support
Co-authored-by: Alistair Evans <alistairjevans@gmail.com>
Co-authored-by: Benjamin Eckel <bhelx@simst.im>
Co-authored-by: Benjamin Eckel <bhelx@users.noreply.github.com>
- Switches from `stack` to `cabal`
- Cleanup SDK code
- Adds release action (still waiting on Hackage upload approval)
Co-authored-by: Steve Manuel <steve@dylib.so>
Creates a new workflow for each language, allowing all languages to run
tests even when one fails
Also disables running on `push` (but once this is merged the workflow
can be manually triggered)
Adds a script to check which runtime API functions are not used in each host SDK. Provides a coverage report with percent of functions called in each SDK.
Co-authored-by: Steve Manuel <steve@dylib.so>
