-
Notifications
You must be signed in to change notification settings - Fork 326
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 single cache file per library #8639
Comments
Jaroslav Tulach reports a new STANDUP for yesterday (2024-01-30): Progress: - fixing GraalVM 24+ "upgrade": 88fd039
Next Day: Dependencies & rewriting caching |
Jaroslav Tulach reports a new STANDUP for today (2024-01-31): Progress: - Maven download tutorial: #8912
Next Day: Dependencies & rewriting caching |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-01): Progress: - single cache per library PR: #8924
Next Day: Rewriting caching & VSCode extension |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-02): Progress: - Better Enso testing: #8940
Next Day: Rewriting caching & VSCode extension debugging
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-03): Progress: - introducing
Next Day: Polishing cache rewrite for integration & VSCode extension debugging |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-04): Progress: - fixing unit tests: d663e06
Next Day: Polishing cache rewrite for integration & VSCode extension debugging
|
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-05): Progress: - CI fighting: https://github.com/enso-org/enso/actions/runs/7773475572/job/21211975666?pr=8924
Next Day: Address
|
Jaroslav Tulach reports a new 🔴 DELAY for yesterday (2024-02-05): Summary: There is 7 days delay in implementation of the Use single cache file per library (#8639) task. I am working at most at 30% capacity this week. Delay Cause: The issue is in review, but it will need some time to finish the reviews and address the comments. Possible solutions: I could rush with integration and then create follow up tickets, but given the reviewing only started, it seems better to give it some time and admit delay. |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-06): Progress: - reacting to review & announcing delay: #8924
Next Day: Address Cache review comments & VSCode extension debugging |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-07): Progress: - mmap only larger files: c061494
Next Day: Address Cache review comments & VSCode extension debugging |
Jaroslav Tulach reports a new STANDUP for yesterday (2024-02-08): Progress: - addressing review comments: 5a4bfa9
Next Day: Integrate |
Jaroslav Tulach reports a new STANDUP for today (2024-02-09): Progress: - Single
Next Day: Write tests for Graal.js multithreding issues |
Follow up of
One of the ideas for future work in #8207 is to benefit from huge cache files mmapped into memory. Rather than having a lot of small .ir files for each module in standard library, let's have just a single file per each library. Btw. there already is such a file for
BindingsMap
s per each library - with the new format we should include whole IR in there (as its parts are loadable lazily on demand)Tasks
The text was updated successfully, but these errors were encountered: