fixed anyinput formats being unreachable#480
Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
found an issue: when converting a renamezip to another archive (ex. tar or lza), it chooses sb3 -> tar instead of sb3 -> zip -> tar which is obviously not the intended behavior |
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
added a penalty to the anyinput formats. right now this works great - sb3 chooses sb3 -> zip -> lza and html doesnt choose something like html -> docs -> zip (which is bad imo, better to just pack it which will make more sense to the user and preserves data better), but if we were to add other non-packing anyinput formats it could cause issues. lmk if thats an issue |
No, it's really not obvious why that's not intended behavior. That's the shorter route, and all the first step does is rename the file anyway. This should be fixed by adjusting your handler, not messing with weights. I don't really know what to do about this all being vibecoded either, I'll leave that decision for tomorrow. |
|
my handler is fine, it compresses anything you give it (just like jszip's handler does) sb3 -> tar means that it just takes the sb3 file and puts it inside of a tar archive (is that really useful?) instead of interpreting the sb3 as zip which makes for a conversion that makes more sense messing with the weights was potentially kinda a bad option though (it may introduce path regressions) so i can undo it |
|
Ah, right. I forgot that the rename handler changes the MIME type too. After properly looking over the code now, I do see merit in de-prioritizing anyInput edges. Though your specific scenario with archives seems like a slightly different issue. To me, it seems like an archive handler should be able to recognize that its input is an archive, regardless of if it's been renamed or if the MIME type has been changed. One solution I see is to add CommonFormats' |
|
Also, this fails to build. Check with |
aargh sorry im stupid!!!!!!!!!!!!!!! fixed now |
i mean that would be nice but imagine if in the future we have some format that is .tar renamed, and then for other archive handlers to handle that properly (ex. lzh and zip) they would have to implement unpacking tars which is absolutely outside of the scope for that handler. honestly i think having zip as a intermediate format that all other archive handlers understand is better, but i can implement detection of specifically just zip-likes in both tar and lzh
theres a ton of formats that use category archive but dont use the Category enum - search "archive" in the repo. (ex .wad, .ic, .lzh... mine too) i mean the example does say that categories are specified as a string? |
|
@p2r3 this can be merged unless you want me to remove anyinput cost |
2 participants
fixing a bug i found when making my tar pr: anyInput handlers did not work at all. (if you convert anything like a png or a text file to a zip or lzh, it always goes through docx and html instead of direct conversion)
the second loop is needed because we need to construct all anyinput paths after all the normal paths are done in order to prioritize nonanyinput paths.
the only issue rn is that anyinput is all or nothing rn - so something like lzh tries to convert anything we try to convert to zip (as it declares that it can accept "any input" and that it produces a zip file as a result) and obviously fails with a (harmless) console error. thatd need deeper changes though, so i left it like that and even with that it works perfectly fine.