-
Notifications
You must be signed in to change notification settings - Fork 1
enhance minifier #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
I got kinda "mentally-blocked" at this point, so I'll write pseudo-code, then translate to Go. I think doing that might help me solve the algorithm faster |
This comment was marked as outdated.
This comment was marked as outdated.
|
No problem!
|
|
Now that bfgo has support for loading "memory-dumps", some of the minifier's assumptions would be broken (such as zero-loop). I propose we add optimization levels (like a compiler). Here's a draft: // Minification level
type Level int
// enum emulation
// https://stackoverflow.com/a/14426447
const (
// only removes non-BF chars,
// therefore it has maximum portability
// across implementations.
BASIC Level = iota
// assumes code isn't a main program.
// useful for "libraries" and "modules", such as subroutines.
LIB Level = iota
// assume all code will be run as-is
MAIN Level = iota
// same as MAIN, but with multi-pass enabled (slow)
MAX Level = iota
)I want to branch that into its own PR, as this PR is already blocking on multiple features |
|
As I mentioned in the updates at #5, I added If we add bf.style inside bfgo, I will use memory-dumping internally without exposing the feature to the user so that the minifier is not affected. The |
|
oh ok. But still, I believe it'll be useful to have (at least) 2 minification levels ( Loading/dumping mem can be useful for users who want to debug their code, although REPL seems to be enough for simple cases, and there's websites that provide full-blown debuggers (even stepping!), so I agree with not implementing mem |
|
Memory-dumping is removed at |
|
I got a new optimization idea! I named it "infinite-loop tail-elimination" (I added it to the task-list): It consists of recognizing "obvious" ♾️-loops of the form If the This allows the minifier to do transformations like these I'm aware |
|
Since the PR has been delayed for a long time, I'll defer ZBL and ILTE to a follow-up PR. I'll implement the mem-sim as it's high-priority |
|
Now that I know "advanced" |
|
For the record, this should (hopefully) be a minimal repro of how I managed to remove all merge-commits while still preserving all changes from both branches: git checkout d755 # main
git switch -c cp-xp # cherry-pick experiment
git cherry-pick ^d755 fa8e # pr-min
git config set rerere.enabled true
git config set rerere.autoUpdate true
# resolve conflicts in `bffmt/minify.go`.
# `git cherry-pick --continue` whenever a merge-commit is found.
git branch -M pr-min
git push --force-with-leaseThe cmds have been expanded (resolve aliases and refs); those weren't the cmds I actually used |
it's a very specialized fn, and having access to its local vars improves performance
IDK why it was that way before
- minor edits to comments - write some pseudo-code to remember how to implement mem-simulator algorithm
Closes #2
+/-x 256 removal" (wrap-around normalizer), "mutual-cancel", and "+/-129+ swapper".or,or]+++[-]->[-](doesn't apply to,,,[-])[...]->[.](deferred, and doesn't apply to[,,,])