introduce a micro stdlib for testing #3531
Conversation
kustosz
requested review from
4e6,
jdunkerley,
radeusgd and
JaroslavTulach
as code owners
| - name: main | ||
| url: https://libraries.release.enso.org/libraries | ||
| libraries: | ||
| - name: Standard.Base |
There was a problem hiding this comment.
I really like the idea. But I think we should call it Micro.Base, so that it is even more obvious that the test is working with the reduced stdlib. Otherwise, I'm afraid that the name might be a source of confusion.
There was a problem hiding this comment.
Right. Gonna go with Microstd tho, so that it's 8 characters and I don't have to fix offset-based tests :P
There was a problem hiding this comment.
@4e6 turns out I cannot do it – the name Standard is assumed in a bunch of places in the codebase, and the interpreter breaks without it. Thoughts?
There was a problem hiding this comment.
I see. Let's live with another Standard.Base for now
There was a problem hiding this comment.
Tracking issue to un-hardcode the interpreter https://www.pivotaltracker.com/n/projects/2539304/stories/182487649
|
Clever! Reminds me of my efforts to define minimal Java. Once I suggested that |
|
Awesome! |
`AtomBenchmarks` are broken since the introduction of [micro distribution](#3531). The micro distribution doesn't contain `Range` and as such one cannot use `1.up_to` method. # Important Notes I have rewritten enso code to manual `generator`. The results of the benchmark seem comparable. Executed as: ``` sbt:runtime> benchOnly AtomBenchmarks ```
This introduces a tiny alternative to our stdlib, that can be used for testing the interpreter. There are 2 main advantages of such a solution: 1. Performance: on my machine, `runtime-with-intstruments/test` drops from 146s to 65s, while `runtime/test` drops from 165s to 51s. >6 mins total becoming <2 mins total is awesome. This alone means I'll drink less coffee in these breaks and will be healthier. 2. Better separation of concepts – currently working on a feature that breaks _all_ enso code. The dependency of interpreter tests on the stdlib means I have no means of incremental testing – ALL of stdlib must compile. This is horrible, rendered my work impossible, and resulted in this PR.
Pull Request Description
This introduces a tiny alternative to our stdlib, that can be used for testing the interpreter. There are 2 main advantages of such a solution:
runtime-with-intstruments/testdrops from 146s to 65s, whileruntime/testdrops from 165s to 51s. >6 mins total becoming <2 mins total is awesome. This alone means I'll drink less coffee in these breaks and will be healthier.Important Notes
Checklist
Please include the following checklist in your PR:
Scala,
Java,
and
Rust
style guides.
./run ide distand./run ide watch.