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.

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

Use the new "module aliases" feature to reduce the size of Uucp #2

Closed
whitequark opened this issue Dec 10, 2014 · 14 comments
Closed

Use the new "module aliases" feature to reduce the size of Uucp #2

whitequark opened this issue Dec 10, 2014 · 14 comments

Comments

@whitequark
Copy link

Currently, using any module from Uucp links in all the data, which somewhat bloats the file. The 4.02 module aliases feature would allow to only link the data that is actually used.

@dbuenzli
Copy link
Owner

This was planned and uucp was explicitly designed with that feature in mind but put on hold because both 4.02 took longer than expected and because I couldn't get proper documentation out of it see #6472.

Besides I didn't commit to a formal policy on ocaml version constraints yet, but I have something in mind like support the current major minus one or two. So that won't happen immediately, but it will eventually.

Also I have to admit that I'm a little bit disappointed by module aliases since they don't really solve the namespace problem but rather multiply the number of visible names without solving the fundamental problem of toplevel names; I do hope however that opam-doc will allow us to hide some of these names in the documentation.

@pqwy
Copy link
Contributor

pqwy commented Feb 14, 2016

Maybe you should revisit this. Anything using notty starts at about 7.5 MB in size.

This, while agreeing that aliases multiply names instead of solving namespacing.

@pqwy
Copy link
Contributor

pqwy commented Feb 28, 2016

@dbuenzli pingu

@dbuenzli
Copy link
Owner

Cute.

@pqwy
Copy link
Contributor

pqwy commented Mar 7, 2016

Any plans here?

@dbuenzli
Copy link
Owner

dbuenzli commented Mar 7, 2016

#2 (comment)

@pqwy
Copy link
Contributor

pqwy commented Mar 7, 2016

This was planned and uucp was explicitly designed with that feature in mind
[...]
So that won't happen immediately, but it will eventually.

That was over a year ago. Do you have any more concrete plans, that you can commit to?

@dbuenzli
Copy link
Owner

dbuenzli commented Mar 7, 2016

That was over a year ago. Do you have any more concrete plans, that you can commit to?

I fully commit to the plan outlined in that comment. If you are not able to read what is written there it is basically wait that 4.03 is out, and see if it the documentation problem is solved.

Besides in which context are these 7.5mo a problem ?

@pqwy
Copy link
Contributor

pqwy commented Mar 7, 2016

In the context of the entire Unicode character database being grafted onto executables which display a progress bar. It makes me uncomfortable even expressing the idea to people.

Now, even for a pretty comprehensive Unicode treatment, I only need Break (directly and via uuseg), Gc (via Break and uuseg), and White (uuseg). Compiled data for these three comes to about 1MB, something I'm far more comfortable with imposing downstream.

@nojb
Copy link

nojb commented Nov 4, 2022

Friendly ping. Six years later, what is the status of this?

@dbuenzli
Copy link
Owner

dbuenzli commented Nov 4, 2022

I'll consider doing this for the next Unicode release.

@nojb
Copy link

nojb commented Nov 4, 2022

I'll consider doing this for the next Unicode release.

Thanks!

@whitequark
Copy link
Author

Thanks @dbuenzli!

@dbuenzli
Copy link
Owner

Well that was a long wait 😬.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants