I think you're right. Performance profile shows lots of long spans relating to that element, and deleting that element makes the page scroll much more smoothly.
There are still other issues though. The performance of this page feels pretty bad in general.
1. Click the box in the bottom right corner to create a cell.
2. Click the box just to the left of that one to create another cell.
3. Drag the cell you created in step 2 to the right. The cell on the bottom right gets pushed downwards, below the grid's lower boundary.
There's a pretty popular `python-is-python3` package in Ubuntu which aliases `python` to `python3`. I used to install that in my dev environment setup scripts, but have since stopped using it for the reasons you mentioned. I've found it best to think of Python 2 and 3 as totally separate languages, so I consider it a good thing that the binary name python3 is unambiguous in all contexts.
Yes, and those work well for smaller workloads, but if you just run 1,000,000 commands with `&` in a `for` loop, it will grind your computer to a halt (if the tasks are modestly resource intensive). GNU parallel will let you run those same 1,000,000 tasks but make sure that only (e.g.) 16 of them are running at once. It's not easy to do that in bash.
The "Problem #2" that they mention also has an easy solution.
If the "intermediate" variable / internal representation is just "the input image but with edges only," then of course you can see internal representations.
When you compute that intermediate variable for the line drawing, it will just happen to behave like the identity function for that particular case. So if you have already filtered out non-edges then the transformation is basically a no-op.
The "types" mismatching
as they mention is not a concern because the type is just "image" i.e. a big vector of HSL values or something. Edge detection is just a convolution filter so it's going to have approximately the same type as the input.
There's an option to output a yarn-compatible lockfile. In practice, I think this means you'd need a branch protection rule to disallow a change to the binary lockfile without updating the yarn lockfile. I'm not sure that complexity is worth the performance gain of the binary format, personally. I think Bun should have an option (maybe in bunrc) to always use the human-readable format, though that detracts from the "batteries included" nature a bit.
There are still other issues though. The performance of this page feels pretty bad in general.