Better runEngineDistribution --run test/Base_Tests "filter"

[JaroslavTulach]

Closes #8601

Pull Request Description

This PR provides following fixes:

• speed runEngineDistribution up by proper time stampingruntime.jar and avoiding it to be re-built with every execution
• allow one to pass a textual filter to test/Base_Tests
• includes Numbers_Spec in the run

As a result one can use following command to execute whole Integers group from Numbers_Spec:

$ runEngineDistribution --run test/Base_Tests Integers
45 tests succeeded.

appropriately use runEngineDistribution --run test/Base_Tests Floats to execute floats, and so on, so on.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  style guides.
• All code has been tested:
  • Unit tests have been added to test suite.

[jdunkerley]

Looks good.
Please do Table_Tests as well.

[JaroslavTulach]

Please do Table_Tests as well.

Done in ed80614, however as @Akirathan pointed out, this only filters by group name. A simple, standardized mechanism to turn argument of main function into useful filter is needed.

[Akirathan]

According to the docs in sbt-assembly: https://github.com/sbt/sbt-assembly/blob/develop/src/main/scala/sbtassembly/MergeStrategy.scala#L82-L85 preferProject picks the dependency that is the first project/internal dependency.

The goal of JPMSUtils.removeAllModuleInfoExcept("runtime") is to drop all the module-info.class files from the resulting JAR except for a single one from the runtime project. I tried locally this change, and the JAR resulting from runtime-fat-jar/assembly unfortunately still contains more module-info.class files:

$ find . -name '*module-info*'
./META-INF/versions/9/module-info.class
./module-info.class
$ find . -name '*module-info*' | xargs javap
module [email protected] {
  requires java.base;
  exports com.fasterxml.jackson.core;
  exports com.fasterxml.jackson.core.async;
  exports com.fasterxml.jackson.core.base;
  exports com.fasterxml.jackson.core.exc;
  exports com.fasterxml.jackson.core.filter;
  exports com.fasterxml.jackson.core.format;
  exports com.fasterxml.jackson.core.io;
  exports com.fasterxml.jackson.core.json;
  exports com.fasterxml.jackson.core.json.async;
  exports com.fasterxml.jackson.core.sym;
  exports com.fasterxml.jackson.core.type;
  exports com.fasterxml.jackson.core.util;
  uses com.fasterxml.jackson.core.ObjectCodec;
}
Compiled from "module-info.java"
open module org.enso.runtime {
  requires java.base;
  requires java.compiler;
  requires java.desktop;
  requires java.se;
  requires jdk.unsupported;
  requires org.graalvm.polyglot;
  requires org.graalvm.truffle;
  requires static org.slf4j;
  uses org.slf4j.spi.SLF4JServiceProvider;
  uses org.enso.interpreter.instrument.HandlerFactory;
  provides  com.oracle.truffle.api.provider.TruffleLanguageProvider with
    org.enso.interpreter.EnsoLanguageProvider,
    org.enso.interpreter.epb.EpbLanguageProvider;
  provides  com.oracle.truffle.api.instrumentation.provider.TruffleInstrumentProvider with
    org.enso.interpreter.instrument.ReplDebuggerInstrumentProvider,
    org.enso.interpreter.instrument.RuntimeServerInstrumentProvider,
    org.enso.interpreter.instrument.IdExecutionInstrumentProvider;
}

If the JVM does not complain about it, we might just leave your change and remove JPMSUtils.removeAllInfoExcept merge strategy.

[Akirathan]

@JaroslavTulach What is your opinion on the following:

$ jar --validate -f runtime.jar
module-info.class in a versioned directory contains incorrect name
module-info.class in a versioned directory contains missing "requires"
module-info.class in a versioned directory contains missing "requires"
module-info.class in a versioned directory contains missing "requires"
module-info.class in a versioned directory contains different "exports"
module-info.class in a versioned directory contains different "provides"
META-INF/versions/9/module-info.class: module-info.class in a versioned directory contains different "version"
entry: META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class, contains a class with different api from earlier version
entry: META-INF/versions/17/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class, contains a class with different api from earlier version
entry: META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class, contains a class with different api from earlier version

?

[Akirathan]

Removed the, now unused, custom merge strategy in a1cbcd6. The tests, and my local brief experimentation, seems to be OK with that. If everything works, this change fixes #8601

[JaroslavTulach]

Thank you for your review and a1cbcd6 fix. I am trying to build runtime.jar from scratch and verify your observations. Doing:

enso$ sbt buildEngineDistribution
enso$ unzip -v runtime.jar | grep module-info
     698  Defl:N      275  61% 2010-01-01 00:00 55091239  META-INF/versions/9/module-info.class
     902  Defl:N      452  50% 2010-01-01 00:00 0dada4e7  module-info.class

I have found two module-info.class files. After 9a233d2cf2 I see only single module info:

enso$ unzip -v runtime.jar | grep module-info
     902  Defl:N      452  50% 2010-01-01 00:00 0dada4e7  module-info.class
enso$ jar --validate -f runtime.jar 
entry: META-INF/versions/11/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class, contains a class with different api from earlier version
entry: META-INF/versions/17/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class, contains a class with different api from earlier version
entry: META-INF/versions/19/com/fasterxml/jackson/core/io/doubleparser/FastDoubleSwar.class, contains a class with different api from earlier version

that seems OKeyish. The module info itself looks fine as well:

enso$ unzip runtime.jar module-info.class
enso$ javap module-info.class 
Compiled from "module-info.java"
open module org.enso.runtime {
  requires java.base;
  requires java.compiler;
  requires java.desktop;
  requires java.se;
  requires jdk.unsupported;
  requires org.graalvm.polyglot;
  requires org.graalvm.truffle;
  requires static org.slf4j;
  uses org.slf4j.spi.SLF4JServiceProvider;
  uses org.enso.interpreter.instrument.HandlerFactory;
  provides  com.oracle.truffle.api.provider.TruffleLanguageProvider with
    org.enso.interpreter.EnsoLanguageProvider,
    org.enso.interpreter.epb.EpbLanguageProvider;
  provides  com.oracle.truffle.api.instrumentation.provider.TruffleInstrumentProvider with
    org.enso.interpreter.instrument.ReplDebuggerInstrumentProvider,
    org.enso.interpreter.instrument.RuntimeServerInstrumentProvider,
    org.enso.interpreter.instrument.IdExecutionInstrumentProvider;
}

I guess this is integratable.

[JaroslavTulach]

Alas, my git push failed on conflicts and I merged incomplete PR. Sorry for that. Here is a continuation:

• Keep only module-info.class in the root of runtime-fat-jar #8961

[Akirathan]

@JaroslavTulach @radeusgd Idea for passing filters as cmd-line args:

main group_filter=Nothing spec_filter=Nothing =
    convert_filter filter =
        case filter of
            _ : Text ->
                Regex.compile filter
            Nothing -> Nothing
    IO.println <| "Group_Filter = " + (group_filter |> convert_filter _ |> _.to_text)
    IO.println <| "Spec_Filter = " + (spec_filter |> convert_filter _ |> _.to_text)

When I run the aforementioned with enso --run tmp.enso one two, it results in:

Group_Filter = (Regex.Value False TRegexObject{source=/one/usg})
Spec_Filter = (Regex.Value False TRegexObject{source=/two/usg})

The only "problem" is when you want to run only some test spec and you don't care about the group name. In that case, you should write something like this:

enso --run tmp.enso '.*' "My test spec name"

What are your thoughts? This is simple and it works. If you are OK with that, we can just replace all the main methods in our tests with the one above.

[JaroslavTulach]

What are your thoughts?

I believe the CLI option shall be simple. E.g. user should be able to specify a single word argument (not two arguments) and it should do the trick.

The search should be heuristic - e.g. alá google search, not an SQL query. Requiring two arguments like in

$ enso --run tmp.enso '.*' "My test spec name"

example just feels too rationalistic and complicated. E.g. I'd prefer pragmatism over rationalism in this CLI interface.