You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can provide some basic impl methods for our structs/enums.
The reasons here would be to make creating snippets/slices easier, and to allow for data validation during snippet/slice creation. For example, we could then validate that an annotation vector fits into slice scope.
We can clean up the internal logic.
A lot of the internal code is suboptimally written and not fully performant.
I'm not sure how/if/when I'd like to tackle the (1), since I'm not sure how much value there is to duplicate the validation which must happen anyway during slice->displaylist creation. I certainly would like to avoid performing the same logic twice.
So maybe it's ok that you construct the Slice which may be bogus, and then when you convert it to display list we can error out if your slice pointers make no sense.
We can think about it more.
But I certainly would like to clean up the inner guts to reduce memory usage and boost perf. I started playing with it, and am getting a nice ~10x perf boost so I'll continue working on the cleanups. The cleanups should not affect the API except of things like zero-copy.
The text was updated successfully, but these errors were encountered:
Since we now have interest from https://github.com/brendanzab/codespan and https://github.com/wycats/language-reporting to merge them into annotate-snippets, I'd like to put some effort into cleaning up the internals of this crate.
There are two levels on which we can work:
The reasons here would be to make creating snippets/slices easier, and to allow for data validation during snippet/slice creation. For example, we could then validate that an annotation vector fits into slice scope.
A lot of the internal code is suboptimally written and not fully performant.
I'm not sure how/if/when I'd like to tackle the (1), since I'm not sure how much value there is to duplicate the validation which must happen anyway during slice->displaylist creation. I certainly would like to avoid performing the same logic twice.
So maybe it's ok that you construct the Slice which may be bogus, and then when you convert it to display list we can error out if your slice pointers make no sense.
We can think about it more.
But I certainly would like to clean up the inner guts to reduce memory usage and boost perf. I started playing with it, and am getting a nice ~10x perf boost so I'll continue working on the cleanups. The cleanups should not affect the API except of things like zero-copy.
The text was updated successfully, but these errors were encountered: