add mem16 etc to docs

[twiddlingbits]

Search for this line: mem8, mem32, memF, and memD can be used to access the WebAssembly memory directly. They are different views on the same memory.

Then add the new signed Arrays as well as mem16.

[JohnDog3112]

Then add the new signed Arrays as well as mem16.

As in also add signed versions to IWasmMemBase? Also, what would they be called? I think the unsigned version is usually prefixed with u while the signed version is assumed. However, I feel like that could cause quite a bit of refactoring to do. So, should the signed versions be something like sMem32 or iMem32?

[twiddlingbits]

hmm, that is an unfortunate situation i got us in. I think i would just change memX to be signed, and add the mem32u, so as to stick with the normal convention. It should be stratforward to change, use the VS Code symbol rename feature. Right click on mem32 (etc) (in probably two places, async and non async -- see export class twrWasmModule extends twrWasmBase implements IWasmModule), and Rename Symbol to mem32u (or whatever name you think is best). Then add a new entry with the old name that is a signed Array. The main issue with this is if a third party is using the variable, their app could break. twrWasmModule is so new that is probably not an issue. But I have the deprecated mem32 still in the module code like this:

 this.mem32 = this.wasmMem.mem32;

For maximum backwards compatibility you would change this to:

this.mem32 = this.wasmMem.mem32u;

And update the deprecated docs to note the inconsistency. Search for "These functions have been deprecated". Do not add the new names (mem32u, etc) to the the code where the deprecated member variables are.

.

[JohnDog3112]

I started changing the mem32's and mem8's to mem32u's and mem8u's. However, I ran into a small roadblock. However, since I left twrWasmModuleAsync and twrWasmModule as mem32 and mem8, I got some errors from applications using twrWasmModule.getString. It seems like the this it binds to becomes twrWasmModule when doing this.getString=this.wasmMem.getString. For now, I'm simply adding a .bind(this.wasmMem) to the end of it, but do you have any better suggestions?

[JohnDog3112]

Second roadblock, it seems like you can't have a two variables between parent and child classes that share the same name but different types. I added the signed versions with the old names (mem8, mem16, mem32) and I'm now getting errors in twrWasmModule about mem8 having two incompatible types (Uint32Array and Int32Array).

For legacy sake should the signed versions of mem8 be named something like mem8i or mem8s instead?

[twiddlingbits]

For now, I'm simply adding a .bind(this.wasmMem) to the end of it, but do you have any better suggestions?

AFAIK that is the correct solution. You should do that to all of the related function calls at the module level. That is a bug in my code, that was not uncovered until you changed mem32 and mem8,

all of these need the bind:

      this.malloc = this.wasmMem.malloc;
      this.free = this.wasmMem.free;
      this.stringToU8=this.wasmMem.stringToU8;
      this.copyString=this.wasmMem.copyString;
      this.getLong=this.wasmMem.getLong;
      this.setLong=this.wasmMem.setLong;
      this.getDouble=this.wasmMem.getDouble;
      this.setDouble=this.wasmMem.setDouble;
      this.getShort=this.wasmMem.getShort;
      this.getString=this.wasmMem.getString;
      this.getU8Arr=this.wasmMem.getU8Arr;
      this.getU32Arr=this.wasmMem.getU32Arr;
   
      this.putString=this.wasmMem.putString;
      this.putU8=this.wasmMem.putU8;
      this.putArrayBuffer=this.wasmMem.putArrayBuffer;

In both twrWasmModule and twrWasmModuleAsync.

[twiddlingbits]

Second roadblock, it

I am not sure what you mean by this problem. Can you provide a code clip or other explanation? For example, I am not sure what classes you are referring to.

If you are referring to adding new member variables to twrWasmModule, i don't think you should do that.

[twiddlingbits]

i pulled your latest changes and built everything and it seems to work.

[twiddlingbits]

I see the issue. I am committing an example fix (adding mem8).

The issue was some lazy coding on my part. In this:

// Partial<IWasmMemory> defines the deprecated, backwards compatible 
// memory access APIs that are at the module level.  
// New code should use wasmMem.
export interface IWasmModule extends Partial<IWasmMemory> {

I am assuming IWasmMemory is the same for the deprecated module functions and the new wasmMem functions. It is not with your latest updates.

[twiddlingbits]

see https://github.com/twiddlingbits/twr-wasm/commit/43dc80645b57897a9c745ae6b3037cb8532f00cd

[twiddlingbits]

At this point you should:

• add the other signed mem arrays (mem16, etc)
• update docs\api\api-ts-memory.md

[JohnDog3112]

And update the deprecated docs to note the inconsistency. Search for "These functions have been deprecated". Do not add the new names (mem32u, etc) to the the code where the deprecated member variables are.

Do you mean that it shouldn't be added to the section code section below it?

Note: In prior versions of twr-wasm, these functions were available directly on the module instance. For example, mod.GetString. These functions have been deprecated. Now you should use mod.wasmMem.getString (for example).

// IWasmMemoryBase operate on shared memory, so they will function in any WasmModule 
export interface IWasmMemoryBase {
   memory:WebAssembly.Memory;
   mem8:Uint8Array;
   mem32:Uint32Array;
   memF:Float32Array;
   memD:Float64Array;
   stringToU8(sin:string, codePage?:number):Uint8Array;
   copyString(buffer:number, buffer_size:number, sin:string, codePage?:number):void;
   getLong(idx:number): number;
   setLong(idx:number, value:number):void;
   getDouble(idx:number): number;
   setDouble(idx:number, value:number):void;
   getShort(idx:number): number;
   getString(strIndex:number, len?:number, codePage?:number): string;
   getU8Arr(idx:number): Uint8Array;
   getU32Arr(idx:number): Uint32Array;
}

Or is there some other deprecated section I missed?

[twiddlingbits]

Or is there some other deprecated section I missed?

I think that's. I think memF should be removed from that section as well? The intent I am going after is to doc the new variables, update any docs that need tweaking to accomplish this, but not add any new variables/features to the deprecated section of the docs (or code), All the new variables should be in the docs and code for wasmMem.