-
Notifications
You must be signed in to change notification settings - Fork 31
Use nix instead of json in output of hackage-to-nix #118
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
Conversation
|
||
-- Avoid issues with case insensitive file systems by escaping upper case | ||
-- characters with a leading _ character. | ||
escapeUpperCase :: String -> String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds a bit like a custom hack to me … what about just add something like a base64 representation of strings we want to encode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this is for filenames, base64 encoding would make it a lot less readable :-/
I wonder if we'd run into camelCase issues.
That would be converted into camel_case, and thus clash with a package named camel_case? Can we rule out that this would happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted the file names to still be human readable. I guess we could include both human and base64 encoding, but then it is kind of a custom format again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My hot take would be that here we had a good opportunity to hide this hack behind an abstraction, meaning a small lib. This is a micro Haskell project I would be glad to publish on Hackage!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we extend the commit message with the motivation and performance observations?
|
||
-- Avoid issues with case insensitive file systems by escaping upper case | ||
-- characters with a leading _ character. | ||
escapeUpperCase :: String -> String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this is for filenames, base64 encoding would make it a lot less readable :-/
I wonder if we'd run into camelCase issues.
That would be converted into camel_case, and thus clash with a package named camel_case? Can we rule out that this would happen?
It replaces
|
We have been using `readFile` and `fromJSON` to read a `.json` a 60MB .json file. This change puts the information contained in the json file into `.nix` files that are imported when needed (rather than all at once). This seems to save around 1s at eval time. Tested with: ``` time nix-instantiate -E '(import ./. {}).pkgs-unstable.haskell-nix.tool "ghc8107" "hello" {}' time nix-instantiate -E '(import ./. {}).pkgs-unstable.haskell-nix.tool "ghc8107" "haskell-language-server" {}' ``` See also input-output-hk/nix-tools#118
We have been using
readFile
andfromJSON
to read a.json
a 60MB .json file. This change puts the information contained in the json file into.nix
files that are imported when needed (rather than all at once). This seems to save around 1s at eval time.Tested with:
See also input-output-hk/haskell.nix#1574