updated to use Clang.jl... still baffling errors #33
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
|
Ok, there is something going on with the snappy lib version 1.1.9. Rather than attempting to resolve this, we can fix everything by capping at 1.1.8 which this PR now does. All tests now passing. Please merge and tag sooner rather than later, we can clean up later, as it sits the package is currently broken. |
Closed
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a work in progress but I need help if anyone can offer it...
I've made various further improvements to modernize this. The main change is that the C calls are now generated by Clang.jl.
However, the actual functionality of this package is still FUBAR. The final test fails, and when used in Parquet2.jl all decompression fails spectacularly. Apparently, the library can't read its own compressed data. I have no clue what's causing this, it seems more likely to happen when the buffer is larger than a certain size, but hell if I know what that is. I switched to a Clang.jl wrapper thinking that maybe there was a call that was structured wrongly that I just couldn't spot, but nope, doesn't seem to have been. There are only a few very simple calls here so I'm very confused and frustrated.
Until this is resolved 0.4 of this package should be considered entirely broken.