Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Commercial user GPL cleanup #16

Closed
alanz opened this issue May 2, 2017 · 1 comment
Closed

Commercial user GPL cleanup #16

alanz opened this issue May 2, 2017 · 1 comment

Comments

@alanz
Copy link
Collaborator

alanz commented May 2, 2017

#15 introduced a GPL library for the Virtual File System Feature.

This is a performance optimisation, and is localised to that module.

Any future commercial user will have to file a PR to either

  • replace the library with an alternative (it is basically a Data.Text interface)
  • let the initial setup include a structure containing the methods from Yi.Rope that are used, and pass in a non-GPL variant for commercial use, thus preserving performance for non-commercial users
  • From GHC 8.2, use backpack to define a mixin with the features required, and use some non-GPL alternative

This issue simply captures the state of play, I (@alanz) have no intention of fixing it.
@alanz alanz mentioned this issue May 2, 2017
Merged
ollef added a commit to ollef/haskell-lsp that referenced this issue Feb 10, 2018
@ollef
Switch to rope-utf16-splay for ropes
c7d904d 
* This makes the licensing story simpler because rope-utf16-splay is
BSD3 licensed. (haskell#16)
* LSP uses UTF-16 code point based indexing, while the Yi rope library
indexes by characters. This means that haskell-lsp would previously not
correctly count characters that are encoded as two code points in
UTF-16. The rope-utf16-splay library uses code point indexing, which
fixes this issue.
* From my benchmarks, this new library, which uses splay trees
internally, can be about twice as fast as finger tree based ones (like
the Yi one) for use cases that are similar to what haskell-lsp might be
doing (many consecutive modifications).
ollef added a commit to ollef/haskell-lsp that referenced this issue Feb 10, 2018
@ollef
Switch to rope-utf16-splay for ropes
9039935 
* This makes the licensing story simpler because rope-utf16-splay is
BSD3 licensed. (haskell#16)
* LSP uses UTF-16 code point based indexing, while the Yi rope library
indexes by characters. This means that haskell-lsp would previously not
correctly count characters that are encoded as two code points in
UTF-16. The rope-utf16-splay library uses code point indexing, which
fixes this issue.
* From my benchmarks, this new library, which uses splay trees
internally, can be about twice as fast as finger tree based ones (like
the Yi one) for use cases that are similar to what haskell-lsp might be
doing (many consecutive modifications).
@ollef ollef mentioned this issue Feb 10, 2018
Merged
ollef added a commit to ollef/haskell-lsp that referenced this issue Feb 11, 2018
@ollef
Switch to rope-utf16-splay for ropes
98c079e 
* This makes the licensing story simpler because rope-utf16-splay is
BSD3 licensed. (haskell#16)
* LSP uses UTF-16 code point based indexing, while the Yi rope library
indexes by characters. This means that haskell-lsp would previously not
correctly count characters that are encoded as two code points in
UTF-16. The rope-utf16-splay library uses code point indexing, which
fixes this issue.
* From my benchmarks, this new library, which uses splay trees
internally, can be about twice as fast as finger tree based ones (like
the Yi one) for use cases that are similar to what haskell-lsp might be
doing (many consecutive modifications).
ollef added a commit to ollef/haskell-lsp that referenced this issue Feb 11, 2018
@ollef
Switch to rope-utf16-splay for ropes
45d9682 
* This makes the licensing story simpler because rope-utf16-splay is
BSD3 licensed. (haskell#16)
* LSP uses UTF-16 code unit based indexing, while the Yi rope library
indexes by characters. This means that haskell-lsp would previously not
correctly count characters that are encoded as two code units in
UTF-16. The rope-utf16-splay library uses code unit indexing, which
fixes this issue.
* From my benchmarks, this new library, which uses splay trees
internally, can be about twice as fast as finger tree based ones (like
the Yi one) for use cases that are similar to what haskell-lsp might be
doing (many consecutive modifications).
ollef added a commit to ollef/haskell-lsp that referenced this issue Mar 23, 2019
@ollef
Switch to rope-utf16-splay for ropes
f31a74f 
* This makes the licensing story simpler because rope-utf16-splay is
BSD3 licensed. (haskell#16)
* LSP uses UTF-16 code unit based indexing, while the Yi rope library
indexes by characters. This means that haskell-lsp would previously not
correctly count characters that are encoded as two code units in
UTF-16. The rope-utf16-splay library uses code unit indexing, which
fixes this issue.
* From my benchmarks, this new library, which uses splay trees
internally, can be about twice as fast as finger tree based ones (like
the Yi one) for use cases that are similar to what haskell-lsp might be
doing (many consecutive modifications).
@cocreature
Copy link
Contributor

Given that the PR to switch to rope-utf16-splay has been merged, I believe that this issue can be closed.

@alanz alanz closed this as completed Jun 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alanz @cocreature