update kernel and add missing functions

[mhmd-azeez]

Fixes #7

[mhmd-azeez]

Not sure why I am getting a "No base constructor has the specified number of type arguments.ts(2508)" error

[bhelx]

maybe related, the dataview constructor has 3 arguments https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DataView/DataView

[mhmd-azeez]

hmmm, that doesn't seem to fix it. To be clear, it builds fine, the only one complaining is the linter

[jrandall]

I can confirm that this works with the most recent released version of c-pdk (1.1.0). Thanks!

[jrandall]

I've just tried to actually exercise some of the logging and am running into some issues with that:

ERROR:  TypeError: Cannot read properties of null (reading 'logLevelToNumber')

[jrandall]

I am seeing some issues with this version using the c-pdk higher-level input loading function extism_load_input().

As far as I can tell, this is because extism_input_length() != extism_length(extism_input_offset()) and it is relying on this being the case.

These are defined in c-pdk to use wasm imports:

• extism_input_length -> input_length
• extism_length -> length_unsafe
• extism_input_offset -> input_offset

In a particular invocation of my plugin with the updated pg_extism on this branch, I am getting:

• extism_input_length(): 13
• extism_input_offset(): 0
• extism_length(extism_input_offset()): 0

[jrandall]

Ah-ha! I think this may be because of a special case in the extism wasm runtime length_unsafe function, which appears to always returns a length of 0 for an offset of 0: https://github.com/extism/extism/blob/98800fe8a0f1154a58530b9eb04b269f25a7ff59/kernel/src/lib.rs#L397-L399

So I guess an offset of 0 is not supposed to be a valid value?

[jrandall]

I've just tried to actually exercise some of the logging and am running into some issues with that:

ERROR:  TypeError: Cannot read properties of null (reading 'logLevelToNumber')

I believe my suggested fixes (e.g. #8 (review)) will address this issue.

[mhmd-azeez]

I am seeing some issues with this version using the c-pdk higher-level input loading function extism_load_input().

As far as I can tell, this is because extism_input_length() != extism_length(extism_input_offset()) and it is relying on this being the case.

These are defined in c-pdk to use wasm imports:

• extism_input_length -> input_length
• extism_length -> length_unsafe
• extism_input_offset -> input_offset

In a particular invocation of my plugin with the updated pg_extism on this branch, I am getting:

• extism_input_length(): 13
• extism_input_offset(): 0
• extism_length(extism_input_offset()): 0

Ah-ha! I think this may be because of a special case in the extism wasm runtime length_unsafe function, which appears to always returns a length of 0 for an offset of 0: https://github.com/extism/extism/blob/98800fe8a0f1154a58530b9eb04b269f25a7ff59/kernel/src/lib.rs#L397-L399

So I guess an offset of 0 is not supposed to be a valid value?

Interesting, we probably should fix the c-pdk to remove that check, @zshipko what do you think?

[jrandall]

I am seeing some issues with this version using the c-pdk higher-level input loading function extism_load_input().
As far as I can tell, this is because extism_input_length() != extism_length(extism_input_offset()) and it is relying on this being the case.
These are defined in c-pdk to use wasm imports:

• extism_input_length -> input_length
• extism_length -> length_unsafe
• extism_input_offset -> input_offset

In a particular invocation of my plugin with the updated pg_extism on this branch, I am getting:

• extism_input_length(): 13
• extism_input_offset(): 0
• extism_length(extism_input_offset()): 0

Ah-ha! I think this may be because of a special case in the extism wasm runtime length_unsafe function, which appears to always returns a length of 0 for an offset of 0: https://github.com/extism/extism/blob/98800fe8a0f1154a58530b9eb04b269f25a7ff59/kernel/src/lib.rs#L397-L399
So I guess an offset of 0 is not supposed to be a valid value?

Interesting, we probably should fix the c-pdk to remove that check, @zshipko what do you think?

To be clear, the check is being done in the core extism runtime, not in c-pdk. It looks like the idea is that MemoryRoot is initialized with input_offset set to 0, and it seems reasonable to report an input_length of 0 if the input is never set.

It seems like the issue here may be that pg_extism never calls input_set to set the input?

[mhmd-azeez]

@jrandall oh yeah! pg_extism is not yet using the newer input functions and handles it outside the kernel. Will fix that!

[mhmd-azeez]

@jrandall thank you very much for pointing out the issue, it should be good now!