Conversation
|
This is something I have tried a few times and got working. However the big issue was always how slow decompling the entire jar is, hopefully I was just being silly as it would be great if this could be done. |
|
I'll try forcing it to decompile the entire Jar first and then time it. |
|
Latest commit decompiles the entire Jar in 11 minutes, which is not too bad, IMO. What do you think? 
|
It's cool, but I think it's unreasonable to make the user wait for 11 minutes for the site to be ready. Especially if we want to be able to link to it from the docs for example. |
|
I imagine it not being enabled by default, and only so for when you want to index the entire Jar, e.g. for full code search, as in #11. |
handle unknown class
modmuss50
left a comment
modmuss50
left a comment
There was a problem hiding this comment.
Just taken a quick look at this it looks good. There is quite a lot going on here, at some stuff that I need to get familar with. I do worry a little bit that this is going to cause browsers to fall over, where it was previously working just fine.
The requirement of the added headers is also less than ideal, but it seems there is no nice way around that.
src/logic/vf.ts
Outdated
| import type * as vf from "@run-slicer/vf"; | ||
|
|
||
| export type Options = Record<string, string>; | ||
| export type Options = vf.Options; | ||
| export type TokenCollector = vf.TokenCollector; | ||
| export type Config = vf.Config; |
There was a problem hiding this comment.
Nice! I knew something wasnt quite right here.
| import { decompileEntireJar, deleteCache, type DecompileEntireJarTask } from "../workers/decompile/client"; | ||
| import { minecraftJar } from "../logic/MinecraftApi"; | ||
|
|
||
| const modalOpen = new BehaviorSubject(false); |
There was a problem hiding this comment.
Nit: can likely just be a useState hook.
There was a problem hiding this comment.
Needs the button and modal to acces it, other modals are also in this way.
| // export async function streamJar(name: string, url: string): Promise<Jar> { | ||
| // const reader = new HttpStreamReader(url); | ||
| // const zip = await read(reader, { | ||
| // naive: true | ||
| // }); | ||
| // return new JarImpl(name, zip); | ||
| // } |
There was a problem hiding this comment.
This isnt actually used atm, as it made too many seperate requests. Maybe just make this return a Zip as I have future plans for this (libraries).
There was a problem hiding this comment.
Since it waits for the zip to read all the stream, why can't it use the fetched blob instead?
| } | ||
|
|
||
| const threads = navigator.hardwareConcurrency || 4; | ||
| const workers = Array.from({ length: threads }, () => createWrorker()); |
There was a problem hiding this comment.
Do you destory the works after decompling/changing version? I had an issue with the indexer workers where they would stay in memory when switching versions: 182462c
There was a problem hiding this comment.
The decompiler workers aren't created for every jar; it will always be $THREAD amounts of them.
For a single class decompile, only the bytes of the target class (and its inner classes) are sent to the worker.
For full jar decompile, the whole jar is sent, and it will be cleaned after the decompile finishes.
I think this way should not leak.
| "@katana-project/zip": "^0.7.1", | ||
| "@monaco-editor/react": "^4.7.0", | ||
| "@run-slicer/vf": "^0.3.2-1.11.2", | ||
| "@run-slicer/vf": "git+https://github.com/deirn/vineflower.js.git#7a257563c0352acf232313612146eae82b5919bf", |
There was a problem hiding this comment.
Note before merging, use a proper version.
|
Would it be possible to add some E2E tests for this, or is it too slow? It would be nice to have some confidence that it works on the 3 main browsers. |
3 participants
Move the decompiling logic to workers.
Also cache decompiled result to IndexedDB.
TODO:
Related to #11