-
Notifications
You must be signed in to change notification settings - Fork 27
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
bounded lenient canonicalization #12
Comments
Ah, good points. When I was writing Puget as part of Vault, the main focus was on canonical printed representations so that the results hashed consistently. Now that its main use is in the REPL, it's probably reasonable to add a There's already some precedent for tweaking the canonicalization with the |
Took a crack at this, I think the updates in e0d3da8 should solve your issue here. I didn't want to make things too complex, so the new
|
This works great for me. Thanks! |
The total ordering is pretty nice, but it has a cost: Printing larger structures is much slower. Although Fipp promises linear time & bounded space, Puget's sorting cannot. Occasionally, I print a pretty large structure with Puget/Whidbey and have a little flashback to a dark time before I wrote fipp.
Incomplete design thought: There should be an option for lenient canonicalization, which recovers the performance promises.
For all
counted?
collections, we could check if(> (count coll) limit)
and, if so, don't sort bother that structure. A reasonable default limit would be some scalar factor (0.5 to 2 or so) of Fipp's print width, which is also used internally for bounding the measurement queue.The text was updated successfully, but these errors were encountered: