12 Apr 2024 |
pat | I understand that current wasm files of monero-ts are beefy, and they will become even more beefy when base64 encoded. | 16:17:51 |
woodser | ouch, couldn't imagine base64ing them | 16:18:41 |
woodser | I don't see the section relevant to wasms though | 16:20:11 |
pat | This?
export const getEmbeddedSha256Binary = () => base64ToBin(sha256Base64Bytes).buffer;
export const instantiateSha256 = async () => instantiateSha256Bytes(getEmbeddedSha256Binary());
| 16:22:23 |
pat | I mean it is not explicit but if one'd follow the calls it will boil down to loading the wasm | 16:23:01 |
woodser | man, hope we wouldn't need to resort to that. it's just loading a wasm file with the new fetch, where it needs to handle file:// protocol I suppose. shouldn't be anything to devious | 16:25:08 |
pat | I am not forcing you, just pointed out the alternative if it is a long-lived issue | 16:26:06 |
woodser | so far it's been long lived, where we have to keep the --no-experimental-fetch option | 16:26:43 |
woodser | but seems to me the people defining on fetch are missing a basic use case, or I'm totally missing something and how it's supposed to be done now | 16:27:31 |
woodser | * but seems to me the people defining fetch are missing a basic use case, or I'm totally missing something and how it's supposed to be done now | 16:27:38 |
pat | right, but I am not node 20, fetch is available there and I am using it to post commands to monerod | 16:28:08 |
pat | primarily the generateblocks for my sandbox | 16:28:39 |
pat | another way around would be to define a static config member like, DEFAULT_REQUEST.requestApi = "xhr" | 16:30:10 |
pat | * another way around would be to define a static config member like, DEFAULT_REQUEST.requestApi = "xhr" if it also affects the wasm file loading | 16:31:35 |
woodser | yeah it might be that only the wasm file loading needs to be customized, and the rest can be with fetch | 16:32:06 |
pat | * right, but I am on node 20, fetch is available there and I am using it to post commands to monerod | 16:32:55 |
woodser | don't know how to do that with the require statements though | 16:32:56 |
woodser | which could also be converted to import and then .default | 16:33:00 |
pat | if it is modern, then you could do const worker = await import("web-worker") | 16:34:10 |
pat | * if it is not cjs, then you could do const worker = await import("web-worker") | 16:34:33 |
woodser | it's all modern as far as I know, only converted to cjs for distribution | 16:34:52 |
woodser | if you take interest in tweaking the library to fix it for your next.js application, we can open bounties to fix these things | 16:35:21 |
pat | would be my pleasure, I enjoy working with monerot-s | 16:35:46 |
pat | * would be my pleasure, I enjoy working with monerot-ts | 16:35:48 |
woodser | would be more than welcome | 16:35:58 |
woodser | let me know of any fixes you have and we can line up the bounties accordingly | 16:39:35 |
pat | sure, not that I have them already, I will come back to you | 16:40:12 |
woodser | ok | 16:40:18 |
| @xh65k:frei.chat left the room. | 17:01:32 |
pat | @woodser I have identified that emsdk 3.1.10 has this fetch issue in the locateFile routine, if I put fetch as undefined there load the worker then reinstate it, all is green, I will try to use the most recent emsdk version to produce wallet_full.js and wallet_keys.js to verify if this workaround is still needed or the issue is fixed in this version | 17:51:40 |