62241430DEV414-7863105946-50
Fix bug EO app calling a varargs func. We reproduced by a Java and EO tests, the bug with exception `You can't overwrite X` when EO app try to call a function that uses varargs as parameter. Now, we must fix it and enable test below and eo test {@code [] > calls-varargs-func} located in `runtime-tests.eo`.
eo-runtime/src/test/java/EOorg/EOeolang/EODataizeAppCallsVarargsFuncTest.java@yegor256yegor256@gmail.com62341430DEV414-aa62591c82-85
Fix bug execute an EO program calling a varargs func. We reproduced by a test bug during execution with exception `You can't overwrite X` when EO app try to call a function that uses varargs as parameter. Now, we must fix it and disable the test (test below).
eo-runtime/src/test/java/org/eolang/DataizedTest.java@yegor256yegor256@gmail.com62456130DEV561-386b582441-45
Add a parameter to bypass/overwrite cache for combination of Local and Caching and Remote. It was suggested by @yegor256 to rely on -U parameter of Maven (https://github.com/objectionary/eo/issues/561#issuecomment-1007128430). If it is possible to access it from the plugin.
eo-maven-plugin/src/main/java/org/eolang/maven/PullMojo.java@yegor256yegor256@gmail.com62549030DEV490-82991e5159-62
Resolve abbreviated hash to a proper hash. In order to avoid collisions resolve hash (or branch) to a complete sha-256 hash of the commit. Use only sha-256 hashes as a caching criteria.
eo-maven-plugin/src/main/java/org/eolang/maven/OyRemote.java@yegor256yegor256@gmail.com64063630DEV636-57a3ebdc80-85
Here, the "property" attribute of the @Parameter annotation is not set. If we set it, in order to enable configuration through command line arguments, the default value won't be set. I don't know how to fix this. Let's investigate what is the right way according to Maven traditions. If we fix this, let's also fix "excludeSources" here and "include/excludeBinaries" in PlaceMojo.
eo-maven-plugin/src/main/java/org/eolang/maven/RegisterMojo.java@yegor256yegor256@gmail.com75275515DEV755-95cd94b4299-302
We need to remove the anything matcher. We can do it only after fixing the eo-hamcrest library when new EO version will be released.
eo-runtime/src/test/eo/org/eolang/runtime-tests.eograurancongr@yandex.ruunknown68430DEV684-1cc2eb4229-32
We need to add ram.ram-slice.slice object here. This object would return ram-slice object and get two parameters: position and size, same as in ram.slice object. And will allow us to make a chain of slice objects.
eo-runtime/src/main/eo/org/eolang/ram.eo@yegor256yegor256@gmail.com104363230DEV632-18c86a2134-37
Implement shift & left methods. New implementation should not truncate length of the original massive. After that, update this PDD to make changes to a corresponding EObytes classes.
eo-runtime/src/main/java/org/eolang/BytesOf.java@rultorme@rultor.com104663230DEV632-74990ab134-37
Current shift implementation does not preserve sing. Add sign-preserving shift if needed. After that, update this PDD to make changes to corresponding EObytes classes.
eo-runtime/src/main/java/org/eolang/BytesOf.java@rultorme@rultor.com1142104630DEV1046-b55b5a3734-37
Use this class for operations on byte-arrays inside eo-runtime, in classes such as EObytes*, Param, etc. Avoid using byte[] directly in all of them.
eo-runtime/src/main/java/org/eolang/BytesOf.java@rultorme@rultor.com1183114230DEV1142-64c12a8f31-35
Long now can only be represented as an array of 8 bytes. This impelementation therefore is broken. Reimplement .as-hash and turn back on tests in bytes-test.eo & string-tests.eo
eo-runtime/src/main/eo/org/eolang/bytes.eorultorme@rultor.com1184114230DEV1142-c462e1ca43-46
This object can be reimplemented in EO with help of bytes.left (and vice versa). Remove either this class or EObytes$EOleft and add a new object to bytes.eo.
eo-runtime/src/main/java/EOorg/EOeolang/EObytes$EOright.javarultorme@rultor.com1207118430DEV1184-826d9a0546-49
This object is almost identical to EOand & EOxor. Extract method for converting Phy[] to Bytes[] to Param. And replace duplicated part this call to this method.
eo-runtime/src/main/java/EOorg/EOeolang/EObytes$EOor.java@rultorme@rultor.com1185114230DEV1142-e53246c034-37
Bytes should be easily convertible to Phi. Add Bytes.ToPhi, and replace all encounters of Data.ToPhi(Bytes) with that. Avoid using byte[] directly.
eo-runtime/src/main/java/org/eolang/BytesOf.javarultorme@rultor.com1076104930DEV1049-0e7c200c93-96
Current implementation supports only character formatting. It means that byte array become an first bytes character string. We need to support another flags, like %a, %o, %s, etc.
eo-runtime/src/main/java/EOorg/EOeolang/EOtxt/EOsprintf.java@rultorme@rultor.com108434830DEV348-ddaf0eaa97-99
This test is broken on Windows. Probably default charset is not UTF-8. Fix the build and enable this test back.
eo-runtime/src/test/eo/org/eolang/string-tests.eo@rultorme@rultor.com108534830DEV348-e3a3606948-51
Make changes to store INT as bytes. After that update this todo. When all data types are stored as bytes, remove data attribute from XML and XSLT templates.
eo-parser/src/main/java/org/eolang/parser/XeListener.java@rultorme@rultor.com1099108530DEV1085-cfcc333630-32
Add conversion from 'bytes' representation back to 'int', 'string' & the rest of types. Then proceed to with the parent todo.
eo-parser/src/main/resources/org/eolang/parser/xmir-to-eo.xsl@rultorme@rultor.com1103109930DEV1099-4eccfaec30-33
Current bytes to string conversion supports only ASCII characters & text blocks. Make it possible to handle any unicode character and double-quoted strings.
eo-parser/src/main/resources/org/eolang/parser/xmir-to-eo.xsl@rultorme@rultor.com1104109930DEV1099-7e313f8a34-36
Add conversion from 'bytes' representation back to 'int', 'double' & the rest of types. Then proceed to with the parent todo.
eo-parser/src/main/resources/org/eolang/parser/xmir-to-eo.xsl@rultorme@rultor.com1110110430DEV1104-7e313f8a34-36
Add conversion from 'bytes' representation back to 'int', 'double' & the rest of types. Then proceed to with the parent todo.
eo-parser/src/main/resources/org/eolang/parser/xmir-to-eo.xsl@rultorme@rultor.com1114111030DEV1110-7e313f8a34-36
Add conversion from 'bytes' representation back to 'int', 'double' & the rest of types. Then proceed to with the parent todo.
eo-parser/src/main/resources/org/eolang/parser/xmir-to-eo.xsl@andreossandreoss@sdf.org1115111030DEV1110-82c0e07837-41
Add XST transformation to convert "$bytes.as-$type" to "$type". I.e "01-.as-bool" becomes "TRUE". Remove analogous conversions from this stylesheet, and only generate "$bytes.as-$type" in order to covert byte-array value back to literal.
eo-parser/src/main/resources/org/eolang/parser/xmir-to-eo.xsl@andreossandreoss@sdf.org1144111530DEV1115-1b7e31b126-30
Add conversions for other types ( int, float, bytes, etc.) and values here. When all simple cases are covered, add support for recursive reduction. Such as 01-.as-bool.as-bytes.as-bool.
eo-parser/src/main/resources/org/eolang/parser/optimize/constant-folding.xsl@rultorme@rultor.com1116111030DEV1110-e2869e1b26-29
Implement eo:bytes-to-int which will convert byte array (i.e. hexadecimal numeric value) to an integer. Change idiomatic.eo to test for various values.
eo-parser/src/main/resources/org/eolang/parser/_funcs.xsl@andreossandreoss@sdf.org1111110430DEV1104-f29eb2d426-29
This code tests for both org.eolang.TYPE and TYPE. This is unnecessary. Investigate why add-default-package.xsl is not always called from eo-maven-plugin and use only qualified object names.
eo-maven-plugin/src/main/resources/org/eolang/maven/pre/data.xsl@rultorme@rultor.com108634830DEV348-be1aef9e52-57
Avoid using Java types in XSLT processing. data.xslt and to-java.xslt use java-type attribute. This attribute is redundant and can be replaced by type inference. This change will ease the task off removing data attribute above.
eo-parser/src/main/java/org/eolang/parser/XeListener.java@rultorme@rultor.com1087106030DEV1060-a52cb0e429-32
The method .empty is not nessesary. Make the create of array possible just by using the object name, i.e `array > a` and remove this method.
eo-runtime/src/main/eo/org/eolang/array.eo@rultorme@rultor.com1088106030DEV1060-769da54136-39
Avoid duplication with a better condition check inside to-java.xslt. Array can be constructed as raw data, and also by .with method.
eo-parser/src/main/resources/org/eolang/parser/_datas.xsl@rultorme@rultor.com1109110730DEV1107-eeae8c2b69-71
Method `jdkExecutable` is duplicated in eo-runtime. Find a way to make it reusable (i.e making it part of VerboseProcess) and remove it from MainTest.
eo-maven-plugin/src/test/java/org/eolang/maven/SnippetTest.javarultorme@rultor.com114541530DEV415-3d65bb6240-44
Test case synthetic-attributes.yaml is disable. Continue to work on that issue, until the test passes. A possible solution is to introduce aliases for objects which are produced by expressions in parenthesis.
eo-parser/src/test/java/org/eolang/parser/PacksTest.java@rultorme@rultor.com1167114530DEV1145-0cc8cffc28-34
This stylesheet just removes alias attribute. A proper processing would be 1) move object one level above 2) add a synthetic name to its attributes 3) put the alias in place of actual object. Continue to work on that issue, until synthetic-attributes.yaml passes.
eo-parser/src/main/resources/org/eolang/parser/synthetic-references.xsl@rultorme@rultor.com2093116790DEV1167-ba59e66628-39
synthetic-attributes. Add more tests with methods. The current number of tests is not enough to implement synthetic-references.xsl transformation. We also have to add tests that checks XMIR with "methods". Something like "((foo 1).with 2).with 3" Then we have to continue to work on that issue, until the next tests pass: synthetic-attributes.yaml synthetic-attributes-double-scope.yaml synthetic-attributes-many-arguments.yaml synthetic-attributes-nested.yaml synthetic-attributes-without-scope.yaml
eo-parser/src/main/resources/org/eolang/parser/synthetic-references.xsl@volodya-lombrozovolodya.lombrozo@gmail.com2110209390DEV2093-7fa3cba528-38
synthetic-attributes. Solution for synthetic-references.xsl. Implement the proper solution for synthetic-references.xsl. Currently we have enough tests that cover all important cases of that feature: synthetic-attributes.yaml synthetic-attributes-double-scope.yaml synthetic-attributes-many-arguments.yaml synthetic-attributes-nested.yaml synthetic-attributes-without-scope.yaml synthetic-attributes-with-doubled-methods.yaml synthetic-attributes-with-nested-methods.yaml
eo-parser/src/main/resources/org/eolang/parser/synthetic-references.xsl@volodya-lombrozovolodya.lombrozo@gmail.com2119211090DEV2110-7761395528-35
Rename synthetic-attributes to synthetic-scopes. We call all attributes in the transformation as "aliases". (you can read more about the original issue and why it is named so right <a href="https://github.com/objectionary/eo/issues/415">here</a>.) which is quite confusing and conflicts with the concept of aliases as foreign references. We should rename the transformation to "scopes" or "synthetic-scopes" and rename the "aliases" attributes in that stylesheet accordingly.
eo-parser/src/main/resources/org/eolang/parser/synthetic-references.xsl@rultorme@rultor.com2120211090DEV2110-fbf50ece57-66
Enable synthetic-references.xsl transformation. Currently, synthetic-references.xsl transformation is disabled because it breaks the integration tests in eo-maven-plugin. The problem is that the transformation breaks add-refs.xsl transformation and to-java.xsl transformation. The reason is that synthetic-references.xsl transformation adds new objects without @line and @pos attributes which are required by add-refs.xsl and to-java.xsl transformations. When the problem is fixed, we should enable synthetic-references.xsl transformation by adding it to the SHEETS array between remove-aliases.xsl and add-default-package.xsl transformations.
eo-parser/src/main/java/org/eolang/parser/ParsingTrain.java@rultorme@rultor.com2216212030DEV2120-ea7680fa455-462
Enable the 'correctly-handles-same-name-attrs' test. The correctly-handles-same-name-attrs test is disabled because it fails with StackOverflowError. We have to understand why it happens and fix it. The first problem is that the error message is not very informative. The second problem is that the test is too complex and it is hard to understand which 'build' object we are using in which case. So, I believe we have to create several small tests that will explain the behaviour better.
eo-runtime/src/test/eo/org/eolang/runtime-tests.eo@rultorme@rultor.com2217212090DEV2120-3c755ab441-44
Use FakeMaven in AssembleMojoTest. It's better to refactor of the tests inside {@link AssembleMojoTest}. Refactoring will simplify the existing code and reduce the total lines number. When the refactoring is done, remove this puzzle.
eo-maven-plugin/src/test/java/org/eolang/maven/AssembleMojoTest.javarultorme@rultor.com2122211090DEV2110-1a17f9f148-53
Missing @line attribute after synthetic-attributes.xsl. We have to fix the problem with missing @line attribute after synthetic-attributes.xsl transformation. The problem is that synthetic-attributes.xsl transformation doesn't copy @line attribute from the original object. When we fix the problem, we have to enable the following test.
eo-parser/src/test/resources/org/eolang/parser/packs/synthetic-attributes-with-add-refs.yaml@volodya-lombrozovolodya.lombrozo@gmail.com2126212290DEV2122-be58f02c56-62
Found more than one target of object at the line. The test below throws exception during the execution of the entire pipeline. The problem is in the synthetic-references.xsl transformation. The transformation adds new objects to the program, probably with incorrect line and pos attributes. Processing terminated by xsl:message at line 358 in to-java.xsl When we fix the problem, we have to enable the following test.
eo-maven-plugin/src/test/resources/org/eolang/maven/packs/pre/synthetic-attributes-with-to-java.yamlrultorme@rultor.com2175212690DEV2126-624e860434-39
Fix problem with redundant objects. Enabling synthetic-attributes-with-to-java.yaml test case still fails. The possible reason is the wrong behaviour of abstracts-float-up.xsl or remove-levels.xsl transformations. As you can see from the comment above - we have strange argument @ that passes into main$t1$first and main$t1$second objects which is considered wrong and can cause some problems.
eo-parser/src/test/resources/org/eolang/parser/packs/optimize/redundant-levels-with-siblings.yamlrultorme@rultor.com2190212690DEV2126-5ddde11a56-58
Found more than one target of object at the line. Processing terminated by xsl:message at line 358 in to-java.xsl When we fix the problem, we have to enable the following test.
eo-maven-plugin/src/test/resources/org/eolang/maven/packs/pre/converts-to-java-with-arrays-and-scopes.yamlrultorme@rultor.com1150114630DEV1146-f869e4b8189-192
At the moment we don't support pattern matching, but double-star means "everything". Let's implement proper matching, where "org.eolang.int" would be matched by "org.*.int" and by "org.**". The same is true about gmiExclude, let's fix it too.
eo-maven-plugin/src/main/java/org/eolang/maven/GmiMojo.javaYegor Bugayenkoyegor256@gmail.com1222106230DEV1062-6d8a243980-83
The mojo doesn't update program version if it exists. This causes versions like `*.*.*` and `0.0.0` are not updated and remain in foreign catalog. This needs to be updated: version must be overridden to correct value.
eo-maven-plugin/src/main/java/org/eolang/maven/MarkMojo.javarultorme@rultor.com1246110530DEV1105-4c34ccb444-46
create load function (it has to be able read by path) It should be able to load data from file We also need to add new unit test
eo-maven-plugin/src/main/java/org/eolang/maven/Home.java@rultorme@rultor.com1247110530DEV1105-a0243dc565-67
we need to modify function. It has to change path by replacing bad characters (not utf-8) or maybe we can invent any other solution
eo-maven-plugin/src/main/java/org/eolang/maven/Home.javarultorme@rultor.com1261124730DEV1247-d57a5fca195-197
we need to modify function. It has to change path by replacing bad characters (not utf-8). We need to choose what symbols we want to replace.
eo-maven-plugin/src/main/java/org/eolang/maven/Home.javaStepa Strunkovstepa.strunkov@gmail.com1248110530DEV1105-2b0b7358155-156
We should remove this function and get rid of using it because it is not really better than simple save
eo-maven-plugin/src/main/java/org/eolang/maven/Home.javarultorme@rultor.com1292124830DEV1248-5239910648-51
we need to implement StLambdaQuiet in yegor256/xsline. It will be similar to StLambda but it will also catch checked exceptions. Then we should change code below
eo-maven-plugin/src/main/java/org/eolang/maven/SpyTrain.javarultorme@rultor.com1326116130DEV1161-bdee702e29-33
Complete implementation of this object in Java. This object should load and execute *.so file. Only one function is stored in *.so file. The signature will be always the same.
eo-runtime/src/main/eo/org/eolang/rust.eorultorme@rultor.com2031132690DEV1326-14112dc144-46
Name functions according to insert's attributes. Now they are named by location. It is better to call it using hash of code and parameters.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2032132690DEV1326-cda54a0147-49
Generate this file at compile phase instead of keep it here. It allows to call any rust insert depending on its attributes.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2033132630DEV1326-493bed2e1-3
Enable only necessary tests. Several checks are not available for the project. For example a lot of package name contains capital letter and such names are conventional.
.codacy.yml@rultorme@rultor.com1327116130DEV1161-b24e6bf339-42
Extract Rust code & parameters from org.eolang.rust objects here. Call rustc with provided dependencies and put binary *.so files to target directory.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com1864132730DEV1327-3956ac9340-43
Now the implementation is unsuitable for solving real problems. It is necessary to pull out the rust code. This can be done in much the same way as TranspileMojo. Rust code should then be compiled into a shared library.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com1876186490DEV1864-a812299e56-59
Implement add_rust.xsl Now the implementation is unsuitable for solving real problems because just adds a rust section to all xmirs. It is necessary to pull out the rust code and put it to rust section.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com1900187690DEV1876-2fce61ab58-61
Expand add-rust.xsl. Now it creates a section 'program/rusts' with nodes 'rust' with attribute 'code'. It is also necessary to add dependencies to every 'rust'
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com1901187690DEV1876-908986ec68-71
EO to rust Naming convention. Come up with such a method of converting "loc" into a name into the legal name of the "rust" function to eliminate the possibility of a collision.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com1877186490DEV1864-29f0679661-64
Extract rust code from rust section BinarizeMojo firstly put the code into rust section in xmir. Then it must be compiled to shared library. It can be implemented via cargo.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com1964187790DEV1877-727c790338-40
Transform source rust file by changing name of function in it to jni standard. It also necessary to add required headers and imports related to jni.
eo-maven-plugin/src/main/java/org/eolang/maven/rust_project/Project.javarultorme@rultor.com1965187790DEV1877-47bf694441-43
Build the rust project via 'cargo build' command. Thins command must be called from right directory. Think of correct compilation errors handling.
eo-maven-plugin/src/main/java/org/eolang/maven/rust_project/Project.javarultorme@rultor.com1337123030DEV1230-0c34d34131-34
Replace this custom {@link SynchronizedTojo} with implementation from Tojo framework once completed in <a href="https://github.com/yegor256/tojos/issues/16">#16</a>. This class should be removed and all usages updated accordingly.
eo-maven-plugin/src/main/java/org/eolang/maven/SynchronizedTojo.javarultorme@rultor.com1338123030DEV1230-026e5a6356-57
Make number of threads used in thread executor within {@link #exec()} method configurable via mojo parameter `threads`. Default value should be 4.
eo-maven-plugin/src/main/java/org/eolang/maven/ParseMojo.javarultorme@rultor.com1347133630DEV1336-2df2eba560-61
Make a number of threads in `exec()` method configurable via mojo parameter `threads`. Default value should be set to 4.
eo-maven-plugin/src/main/java/org/eolang/maven/OptimizeMojo.javarultorme@rultor.com1348133630DEV1336-4642722086-89
Replace creation of new `Train` instances for each parsing task to a single `Train>Shift< TRAIN`, once `TrClasspath` is thread-safe (solved by <a href="https://github.com/jcabi/jcabi-xml/issues/185"/>).
eo-maven-plugin/src/main/java/org/eolang/maven/OptimizeMojo.javarultorme@rultor.com1370129960DEV1299-22a667db30-33
Implement test that will check output of stdout. That should proove that there is no double printage, when methods lt., gt., lte., gte. are called.
eo-runtime/src/test/eo/org/eolang/seq-tests.eo@rultorme@rultor.com1374117490DEV1174-05a7b1c330-32
It's much better to move CommitHash class and all his implementations (including all connected classes) to a separate package. The example of the package name: `org.eolang.maven.hash`
eo-maven-plugin/src/main/java/org/eolang/maven/CommitHash.javavolodya-lombrozovolodya.lombrozo@yandex.ru1376135230DEV1352-39528ceb47-48
Prohibit absolute paths in methods `save`, `load`, `exists`. Throw an exception in case absolut path is given for these methods.
eo-maven-plugin/src/main/java/org/eolang/maven/Home.javarultorme@rultor.com1377135230DEV1352-7c5eb2d2161-166
Make `rel` method strictly relative to base. In most cases `rel` is used with empty `Home()` and given absolute path which is not part of it. So it just returns absolute path. Throw an exception in case give path is not sub-path of a base. Along with that revise all usages of this method and replace applicable with just `Path.relativize` or plain local vars.
eo-maven-plugin/src/main/java/org/eolang/maven/Home.javarultorme@rultor.com1378135230DEV1352-5ea27325208-210
Move utility `clean` method out of `Home` class. Create maybe separate class for this. Consider removing this method at all as it seems does nothing useful. Update all usages of this method.
eo-maven-plugin/src/main/java/org/eolang/maven/Home.javarultorme@rultor.com1381117490DEV1174-f084259e59-61
The wrong naming. It isn't a `hash` - it's a `tag`. We have to rename that property. Also it's important to check if we don't break something by such a renaming.
eo-maven-plugin/src/main/java/org/eolang/maven/PullMojo.javavolodya-lombrozovolodya.lombrozo@yandex.ru1382117490DEV1174-32383060101-103
The code duplication with ChText. It's better to reuse the logic of parsing text source from ChText class. Maybe we can implement caching mechanism in a way to avoid using map directly.
eo-maven-plugin/src/main/java/org/eolang/maven/ChRemote.javavolodya-lombrozovolodya.lombrozo@yandex.ru1397138290DEV1382-5825e08337-40
We definitely have to split {@link org.eolang.maven.ChRemote} class to a two different classes: ChRemote and ChCached - in that case we will able to remove static methods and reuse ChCached somewhere else (not only in ChRemote). After implementation of ChCached - it's important remove CACHE from ChRemote.
eo-maven-plugin/src/main/java/org/eolang/maven/ChRemote.javarultorme@rultor.com1385136190DEV1361-d1d958c139-40
The class without tests. We definitely have to write some tests in order to make the class possible for future refactoring and easy maintainance.
eo-maven-plugin/src/main/java/org/eolang/maven/DcsNoOneHasTransitive.javarultorme@rultor.com1386136190DEV1361-2e51fcf234-38
Hardcoded version of EoRuntimeDependency. See the EoRuntimeDependency constructor for more info. It's much better to determine the version of the runtime library dynamically. For example, we can fetch the latest version by http or from config files.
eo-maven-plugin/src/main/java/org/eolang/maven/DcsWithRuntime.javarultorme@rultor.com1387117490DEV1174-ff28865734-38
Add implementation for {@link org.eolang.maven.ChPattern} class. Now it has dummy behaviour. When {@link org.eolang.maven.ChPattern} will be finished we can remove '@Disabled' annotation from the next tests: - org.eolang.maven.PullMojoTest#pullsUsingOfflineHash(Path) - org.eolang.maven.ChPatternTest#returnsCorrectHashByPattern(String, String, String)
eo-maven-plugin/src/main/java/org/eolang/maven/ChPattern.javarultorme@rultor.com1395132330DEV1323-f376339c43-47
Create `ProbeMojo` and include it into assemble cycle. It has to be included between discover and pull steps. New mojo needs to go through all `probe` metas in XMIRs, try to locate the objects pointed by `probe` in Objectionary and if found register them in `foreign.csv`.
eo-maven-plugin/src/main/java/org/eolang/maven/AssembleMojo.javarultorme@rultor.com1677139530DEV1395-4efb8b76180-182
Rewrite lines 185-200 as fully `cactoos` style to make to code more convenient. So there is will no "imperative" `forEach()` in line 194.
eo-maven-plugin/src/main/java/org/eolang/maven/ProbeMojo.javaYegor Bugayenkoyegor256@gmail.com1678139530DEV1395-62820c0c222-223
Need to add the logic of "hasReservedChars" method to add-probes.xsl". After that, the method in this class need to be removed.
eo-maven-plugin/src/main/java/org/eolang/maven/ProbeMojo.javaYegor Bugayenkoyegor256@gmail.com1679139540DEV1395-b6efb03650-53
Rewrite this class via using a new method for testing Mojos with using `FakeMaven` class. At the moment, this class has a lot of "noise"-code. So, by using `FakeMaven` it will be more clear.
eo-maven-plugin/src/test/java/org/eolang/maven/ProbeMojoTest.javaYegor Bugayenkoyegor256@gmail.com1700139530DEV1395-c0569c3e230-231
Need to add the logic of "missesReservedChars" method to add-probes.xsl". After that, the method in this class need to be removed.
eo-maven-plugin/src/main/java/org/eolang/maven/ProbeMojo.javarultorme@rultor.com1412117490DEV1174-4058951458-61
The wrong naming. It isn't a `hash` - it's a `tag`. We have to rename that property. Also it's important to check if we don't break something by such a renaming. @since 0.21.0
eo-maven-plugin/src/main/java/org/eolang/maven/PullMojo.javarultorme@rultor.com1431122390DEV1223-c08eee6b140-143
Implement caching for optimization step. After implementation don't forget to remove '@Disabled' annotation from the next tests: - 'getsAlreadyOptimizedResultsFromCache' - 'savesOptimizedResultsToCache'
eo-maven-plugin/src/test/java/org/eolang/maven/OptimizeMojoTest.javarultorme@rultor.com1442143190DEV1431-4de3d36340-43
Unit test are required. We have to test different cases like: - if XML file is already in cache - if XML file is absent - if some {@link java.io.IOException} happens
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com1443143190DEV1431-d4218ffb278-280
move that method implementation to a separate class under {@link org.eolang.maven.optimization} package. Probably, after implementation we will able to remove {@link org.eolang.maven.optimization.OptLambda}.
eo-maven-plugin/src/main/java/org/eolang/maven/OptimizeMojo.javarultorme@rultor.com1471131930DEV1319-d1162eae125-126
If all .class files for a dependency are removed then unplaced attribute should be set to `true` for a dependency jar entry as well.
eo-maven-plugin/src/main/java/org/eolang/maven/UnplaceMojo.javarultorme@rultor.com1475102430DEV1024-be5231a943-45
Need to figure out, which errors need to be "critical", same as "duplicate-names" error. After that move them to "critical-errors" directory.
eo-parser/src/main/java/org/eolang/parser/ParsingTrain.javarultorme@rultor.com1479141790DEV1417-1e98004e38-39
Make `FakeMaven.exec()` return a `HashMap` with all files created in the directory and their relative names. Then, we can assert on this hash map.
eo-maven-plugin/src/test/java/org/eolang/maven/FakeMaven.javarultorme@rultor.com1488147990DEV1479-9e6d5e0090-92
The method withDefaults() has to be called right in the exec() method. We should set default properties only if they aren't set using `with()` method. Also it's important to remove withDefaults() method from tests.
eo-maven-plugin/src/test/java/org/eolang/maven/FakeMaven.javarultorme@rultor.com1489147990DEV1479-03b130b4117-119
The method withEoForeign() has to be deleted. We can move the logic of creation eo-foreign.* file into exec() function directly. Also it's important to remove the method from tests.
eo-maven-plugin/src/test/java/org/eolang/maven/FakeMaven.javarultorme@rultor.com149048590DEV485-f1fd9ef185-90
The {@link org.eolang.parser.Syntax} by default just write warning to the log about redundant parentheses because some objects from objectioanry already contain redundancy parentheses in their source code that causes exceptions during parsing if {@link org.eolang.parser.Syntax#redundancy} is true. By that reason it's important to fix all redundancy parentheses in the objectionary. Then we will be able to remove 'redundancy' flag and check all eo programs for redundant parentheses by default.
eo-parser/src/main/java/org/eolang/parser/Syntax.javarultorme@rultor.com1505150230DEV1502-8fdd46e0302-304
For some reason this test doesn't work any more, after I changed the algorithm inside WHILE atom. Can't figure out why it doesn't work, let's find out and enable this test back again.
eo-runtime/src/test/eo/org/eolang/runtime-tests.eo@yegor256yegor256@gmail.com1514149430DEV1494-e338b825155-158
We have some doubts about using Logger.warn in initField method. Since it's important to notice the developer during of using the plugin that the property can't be set to the Mojo, we can't just remove Logger.warn. On the other hand, we will see warnings all the time during unit testing, which can be an insignificant problem.
eo-maven-plugin/src/main/java/org/eolang/maven/Moja.javarultorme@rultor.com1582157530DEV1575-0b49c4eb164-164
Set 'verify' phase for the 'project-validate'. Replace the phase with 'verify' when #1576 will finished. This action will make the integration test work. -->
eo-runtime/pom.xml@rultorme@rultor.com1587158490DEV1584-082116ed116-116
Set failOnWarning to 'true'. It's not a good idea to allow deploy artifacts with warnings. It's only temporary solution. -->
eo-runtime/pom.xml@volodya-lombrozovolodya.lombrozo@yandex.ru1598159530DEV1595-30597d8f165-168
Make method 'deps' testable. For now it's not possible to test 'ignoreTransitive=false' branch because it's hard to mock all required fields. Maybe we should provide a chance to mock all dependencies related to maven or even extract new classes.
eo-maven-plugin/src/main/java/org/eolang/maven/ResolveMojo.javarultorme@rultor.com1607157430DEV1574-650f37ca46-49
MonoTojo is not thread safe. It's not possible to use it in parallel. It should be fixed. When <a href="https://github.com/yegor256/tojos/issues/50"> the issue</a> will be fixed, remove the @Disabled annotation from the test below.
eo-maven-plugin/src/test/java/org/eolang/maven/CatalogsConcurrencyTest.javarultorme@rultor.com1616161430DEV1614-0453e66835-36
This class don't have enough tests. We need to add more, at least for the next methods: toString(), φTerm(), copy(), put().
eo-runtime/src/main/java/org/eolang/AtConst.java@volodya-lombrozovolodya.lombrozo@gmail.com1617161430DEV1614-2eb2b1c332-33
This class don't have enough tests. We need to add more, at least for the next methods: toString(), φTerm(), copy(), put(), get().
eo-runtime/src/main/java/org/eolang/AtLogged.java@volodya-lombrozovolodya.lombrozo@gmail.com1664161730DEV1617-eb1a6d1b34-35
Use logger instead of System.out.println. It's much better to use standard logger in that class. Examples of using logger are inside {@link PhDefault} or {@link Dataized}.
eo-runtime/src/main/java/org/eolang/AtLogged.java@rultorme@rultor.com1618161430DEV1614-fb4fb25c31-32
This class don't have enough tests. We need to add more, at least for the next methods: toString(), φTerm(), copy(), put(), get(), label().
eo-runtime/src/main/java/org/eolang/AtLocated.java@volodya-lombrozovolodya.lombrozo@gmail.com1619161430DEV1614-917953e434-35
This class don't have enough tests. We need to add more, at least for the next methods: equals(), toString(), φTerm(), copy(), attr(), locator().
eo-runtime/src/main/java/org/eolang/PhLogged.java@volodya-lombrozovolodya.lombrozo@gmail.com1622156730DEV1567-f68ff78b41-44
In method `contains()` we catch an `IOException` for flow control. Now, if the exception occurred, this method returns `false`. Need to allow it to not use this approach, since control-flow via Exceptions is prohibited.
eo-maven-plugin/src/main/java/org/eolang/maven/objectionary/OyRemote.javaMikhailLipaninmikhail.lipanin@gmail.com1623156730DEV1567-4fb86abf40-43
The "putsObjectToLocalCache" is very complicated, since it checks a lot of things like methods "get" and "contains" in Objectionary, work of "OyFallback", and behaviour of "OyCaching". Need to split this test into several tests to check every part separately.
eo-maven-plugin/src/test/java/org/eolang/maven/objectionary/OyFallbackTest.javaMikhailLipaninmikhail.lipanin@gmail.com1644156930DEV1569-254a5fb633-37
Now, this class is a configurable. This is not a good practice. More technically, encapsulated properties must not be used to change the behavior of an object. Need to use composable decorators to make this class not configurable.
eo-maven-plugin/src/main/java/org/eolang/maven/hash/ChResolve.javarultorme@rultor.com1645156930DEV1569-cc8ee66838-40
Need to rename this class to a more correct one. The correct one name will consist of prefix "Ch" and a noun or adjective.
eo-maven-plugin/src/main/java/org/eolang/maven/hash/ChResolve.javarultorme@rultor.com1673158930DEV1589-9aa5ee7237-38
Add fine grained tests for DcsEachWithoutTransitive. It's important to add new unit tests for different cases including dome garbage inputs.
eo-maven-plugin/src/main/java/org/eolang/maven/DcsEachWithoutTransitive.javavolodya-lombrozovolodya.lombrozo@gmail.com1800125330DEV1253-c101194f28-30
Allow division by float zero in EOfloat$EOdiv for being able to make float.nan, float.positive-infinity and float.negative-infinity decorated 0.0.div 0.0, 1.0.div 0.0 and -1.0.div 0.0 accordingly
eo-runtime/src/main/eo/org/eolang/nan.eo@rultorme@rultor.com1801125330DEV1253-cf6eb09a32-35
Add extra conditions in Data.ToPhi.toPhi() method for checking if given object is Double.NaN, Double.POSITIVE_INFINITY or Double.NEGATIVE_INFINITY and convert them to Phi objects (EOfloat$EOnan, EOfloat$EOpositive_infinity and EOfloat$EOnegative-infinity)
eo-runtime/src/main/eo/org/eolang/nan.eo@rultorme@rultor.com1802125330DEV1253-b8f8376937-39
After allowing division by zero float in EOfloat$EOdiv make float.nan, float.positive-infinity and float.negative-infinity decorated 0.0.div 0.0, 1.0.div 0.0 and -1.0.div 0.0 accordingly
eo-runtime/src/main/eo/org/eolang/nan.eo@rultorme@rultor.com1803179130DEV1791-3261ce9841-45
Remove unwanted objects from nan, +inf and -inf. Since these are object are float numbers but special - they should not have extra and unwanted objects that usual float does not have like: neq, signum, as-int. as-bytes also can be removed because it can be got from the result of @ object
eo-runtime/src/main/eo/org/eolang/nan.eo@rultorme@rultor.com1804172390DEV1723-32fae63091-95
Enable runsAllSpinners test. This test disabled because it requires foreign eo objects from the internet. We need to find a way to mock them or to put into eo-runtime.jar. You can read more about the problem <a href="https://github.com/objectionary/eo/issues/1724">here</a>. Also it's important to remove bytes-as-array.eo and list.eo from the test resources.
eo-maven-plugin/src/test/java/org/eolang/maven/SnippetTest.javarultorme@rultor.com2125180430DEV1804-0c2079fd293-296
Introduce OyFilesystem instead of using OyFake. The code below can be moved into separate class with the possible name OyFilesystem. This class will upload eo sources from filesystem. By that change we will simplify the SnippetTest itself and will be able to use OyFilesystem in some other cases.
eo-maven-plugin/src/test/java/org/eolang/maven/SnippetTest.javarultorme@rultor.com2128212530DEV2125-11b289da42-44
Add unit tests for OyFilesystemSources. The tests should check that OyFilesystem can get an object from the filesystem and that it can check if an object exists in the filesystem.
eo-maven-plugin/src/main/java/org/eolang/maven/objectionary/OyFilesystem.javavolodya-lombrozovolodya.lombrozo@gmail.com1806179930DEV1799-32659a0629-31
Make "+inf" and "-inf" looked like float. Refactor objects plus, minus, times, div in +inf and -inf so they are able to process multiple arguments
eo-runtime/src/main/eo/org/eolang/positive-infinity.eo@rultorme@rultor.com1824180630DEV1806-8a1e1fbc62-64
Make positive-infinity.times and negative-infinity.times worked with multiple arguments without using objects from eo-collections. See positive-infinity.plus and negative-infinity.plus as an example
eo-runtime/src/main/eo/org/eolang/positive-infinity.eo@rultorme@rultor.com1825180630DEV1806-be69b5fb126-128
Make positive-infinity.minus and negative-infinity.minus worked with multiple arguments without using objects from eo-collections. See positive-infinity.plus and negative-infinity.plus as an example
eo-runtime/src/main/eo/org/eolang/positive-infinity.eo@rultorme@rultor.com1826180630DEV1806-865a59ed133-135
Make positive-infinity.div and negative-infinity.div worked with multiple arguments without using objects from eo-collections. See positive-infinity.plus and negative-infinity.plus as an example
eo-runtime/src/main/eo/org/eolang/positive-infinity.eo@rultorme@rultor.com1809154290DEV1542-94d035b157-60
Add xsl transformation that checks the presence of +version meta. The version meta have to be correct. It can be divided by 2 xsl checks.
eo-parser/src/main/java/org/eolang/parser/ParsingTrain.javarultorme@rultor.com1818181230DEV1812-9ede52a344-46
Remake "switch" without using "QQ.collections.list". eo-runtime must be independent of other packages so need to implement switch using recursion not "QQ.collectioins.list". See "float.minus" as an example
eo-runtime/src/main/eo/org/eolang/switch.eo@maxonfjviponmtrunnikov@gmail.com1820106030DEV1060-a940be9c29-32
The method .empty is not nessesary. Make the create of tuple possible just by using the object name, i.e `tuple > a` and remove this method.
eo-runtime/src/main/eo/org/eolang/tuple.eo@rultorme@rultor.com1821179030DEV1790-b6768978236-236
After the new version of the eo-runtime library, which includes 'tuple' classes, is deployed to Maven Central, we should remove the plugin from the pom.xml file. However, a better solution would be to move all integration tests from the eo-maven-plugin to the eo-parent project since these tests depend on eo-parser, eo-maven-plugin, and eo-runtime collectively. -->
eo-maven-plugin/pom.xmlrultorme@rultor.com1849184290DEV1842-6aa1ed7830-33
We can add method 'outputDirectory()' in order to replace hardcoded static variables like ParseMojo.DIR, ResolveMojo.DIR, OptimizeMojo.DIR, CopyMojo.DIR, TranspileMojo.DIR, etc. The CompilationStep interface could also define other common behaviors shared among different Mojos.
eo-maven-plugin/src/main/java/org/eolang/maven/CompilationStep.javarultorme@rultor.com1857122630DEV1226-84e22b8e160-162
new FtCached(hash, cache, origin) should be replaced with a new constructor that uses the current eo-maven-plugin version - new FtCached(CacheVersion, cache, origin). This will allow us to invalidate the cache when the plugin version changes.
eo-maven-plugin/src/main/java/org/eolang/maven/ParseMojo.javarultorme@rultor.com1904132030DEV1320-7d394273158-160
Refactor PlaceMojo#place method in order to reduce complexity. When the method will be refactored we have to remove all warning suppressing from checkstyle and PMD.
eo-maven-plugin/src/main/java/org/eolang/maven/PlaceMojo.javarultorme@rultor.com1928189430DEV1894-1f27a75b252-255
Replace PlaceMojo#placedCache crutch with an appropriate solution from Tojos library. The original problem is that Tojos has not so optimal reading mechanism and it's not efficient to read row by row from tojos. You can check the progress <a href="https://github.com/yegor256/tojos/issues/60">here</a>.
eo-maven-plugin/src/main/java/org/eolang/maven/PlaceMojo.javarultorme@rultor.com1934190730DEV1907-be29faa848-52
Enable HomeTest.throwsExceptionOnAbsolute(). The test fails on Windows with no error thrown. It means that this test didn't throw IllegalArgumentException when we are trying to check existence of file in temporary directory. Possible reason is Home.onlyRelative() method.
eo-maven-plugin/src/test/java/org/eolang/maven/util/HomeTest.javarultorme@rultor.com1953129960DEV1299-fdd4d59330-33
Implement test that will check output of stdout. That should proven that there is no double printage, when methods lt., gt., lte., gte. are called.
eo-runtime/src/test/eo/org/eolang/seq-tests.eo@rultorme@rultor.com1959189730DEV1897-b918ace1105-113
Refactor regexp in `RedundantParenthesis`. The Java regex engine uses recursive method calls to implement backtracking. Therefore when a repetition inside a regular expression contains multiple paths (i.e. the body of the repetition contains an alternation (|), an optional element or another repetition), trying to match the regular expression can cause a stack overflow on large inputs. This does not happen when using a possessive quantifier (such as *+ instead of *) or when using a character class inside a repetition (e.g. [ab]* instead of (a|b)*). Refactor this repetition that can lead to a stack overflow for large inputs. (line 113)
eo-parser/src/main/java/org/eolang/parser/RedundantParentheses.javaMax Petrov40247101+mximp@users.noreply.github.com1960189730DEV1897-ad91fbed85-89
Close `Stream` object in `FtDefault`. Connections, streams, files, and other classes that implement the Closeable interface or its super-interface, AutoCloseable, needs to be closed after use. Use try-with-resources or close this "Stream" in a "finally" clause.. (line 90)
eo-maven-plugin/src/main/java/org/eolang/maven/footprint/FtDefault.javaMax Petrov40247101+mximp@users.noreply.github.com1961189730DEV1897-5e29a33b195-197
Close `JsonReader` object in `DcsJson`. SonarCloud mandates readers to be closed. Use try-with-resources or close this "JsonReader" in a "finally" clause. (line 203)
eo-maven-plugin/src/main/java/org/eolang/maven/dependencies/DcsDepgraph.javaMax Petrov40247101+mximp@users.noreply.github.com1962189730DEV1897-ea29af16120-124
Close `Stream` object in `Walk`. Connections, streams, files, and other classes that implement the Closeable interface or its super-interface, AutoCloseable, needs to be closed after use. Use try-with-resources or close this "Stream" in a "finally" clause.. (line 131)
eo-maven-plugin/src/main/java/org/eolang/maven/util/Walk.javaMax Petrov40247101+mximp@users.noreply.github.com1986182930DEV1829-7107521248-50
BinarizeMojoTest.binarizesWithoutErrors() fails sometimes. Apparently, the test was merged without appropriate checks verification. The test should be fixed and then enabled.
eo-maven-plugin/src/test/java/org/eolang/maven/BinarizeMojoTest.javavolodya-lombrozovolodya.lombrozo@gmail.com1989196990DEV1969-7863a9b545-47
Remove all ATTR_* constants from AssembleMojo class. We have to replace all hardcoded ATTR_* attributes with corresponding methods from ForeignTojos and ForeignTojo classes. It will increase maintainability of the code.
eo-maven-plugin/src/main/java/org/eolang/maven/AssembleMojo.javarultorme@rultor.com2018198930DEV1989-9b8b16d253-56
Enable BinarizeMojoTest.binarizesWithoutErrors() test. The test is disabled because it fails on systems that don't hava install rust. We have to invent a way to check installed rust on the system before running that test. The logic is similar to {@link org.eolang.maven.OnlineCondition}.
eo-maven-plugin/src/test/java/org/eolang/maven/BinarizeMojoTest.javarultorme@rultor.com1990196930DEV1969-544e0a6b149-151
Add more meaningful name for the xmir2 attribute. I believe that instead of xmir2 we have to invent something more meaningful and change all related methods and parameters that use xmir2 abbreviation.
eo-maven-plugin/src/main/java/org/eolang/maven/tojos/ForeignTojos.javarultorme@rultor.com2014199630DEV1996-4a25c7ad107-107
Enable parallel run of all tests in eo-runtime. For now we are experience some problems when concurrent mode is enabled. We have to investigate the problem and make all tests in eo-runtime run in parallel.-->
eo-runtime/pom.xml@rultorme@rultor.com2015199630DEV1996-dfdf2dcc43-48
Make LogFormatTest run tests in parallel. Currently all tests in this class are executed in the same thread. This is done by the annotation @Execution(ExecutionMode.SAME_THREAD) on the class. This is a temporary solution because the class has some concurrency problems. We need to make the tests in this class run in parallel and then remove the annotation. Also we have to remove @Disabled from the test method
eo-maven-plugin/src/test/java/org/eolang/maven/LogFormatTest.javarultorme@rultor.com2016199630DEV1996-4117854c49-53
Make PlaceMojoTest run tests in parallel. Currently all tests in this class are executed in the same thread. This is done by the annotation @Execution(ExecutionMode.SAME_THREAD) on the class. This is a temporary solution because the class has some concurrency problems. We need to make the tests in this class run in parallel and then remove the annotation.
eo-maven-plugin/src/test/java/org/eolang/maven/PlaceMojoTest.javarultorme@rultor.com2017199630DEV1996-cf9e8e9139-43
Make BinarizeMojoTest run tests in parallel. Currently all tests in this class are executed in the same thread. This is done by the annotation @Execution(ExecutionMode.SAME_THREAD) on the class. This is a temporary solution because the class has some concurrency problems. We need to make the tests in this class run in parallel and then remove the annotation.
eo-maven-plugin/src/test/java/org/eolang/maven/BinarizeMojoTest.javarultorme@rultor.com2044120590DEV1205-36a795cd38-46
cti: Use normal string literals instead of hex literals. Currently we add errors for cti with hex representation of the error message which looks ugly. We should use normal string literals instead, but for now it seems impossible since during parsing we already have hex representation of the error message in cti. By that reason, the 'fails-since-deprecated' test passes successfully, but it should fail since it uses cti with "error" level. See cti-adds-error.yaml, cti-adds-warning.yaml pack tests and cti-adds-errors.xsl transformation for more details.
eo-runtime/src/test/eo/org/eolang/cti-test.eo@rultorme@rultor.com2057204630DEV2046-deb7b8e4239-243
Enable removing transpiled files. We ignored that method by using .filter(tojo -> false) statement, because it created some problems like the next one: <a href="https://github.com/objectionary/eo/issues/2046">#2046</a> We have to decide if we need to remove transpiled files or not.
eo-maven-plugin/src/main/java/org/eolang/maven/TranspileMojo.javarultorme@rultor.com2066120630DEV1206-1613cc9f40-44
Create a summary file "target/eo/universe.tex". According to the <a href="https://github.com/objectionary/eo/issues/1206">issue</a> we need to generate summary in universe.tex file, which will include all generated objects. And this file should be a standalone compilable document.
eo-maven-plugin/src/main/java/org/eolang/maven/LatexMojo.javarultorme@rultor.com2067120630DEV1206-e1d7d26245-48
Generate a standalone compilable document from each of the file in "latex" directory. All of this files are already ".tex" files. But they are contain only the EO code without LaTex structure.
eo-maven-plugin/src/main/java/org/eolang/maven/LatexMojo.javarultorme@rultor.com2089206730DEV2067-cbe8080e35-37
We need to refactor LatexTemplate class. And to remove redundant parts in the code, like DOM variables and license header. E.g.: "<listing># The MIT License (MIT)...</listing>".
eo-maven-plugin/src/main/java/org/eolang/maven/latex/LatexTemplate.java@rultorme@rultor.com2080207290DEV2072-740fdee740-47
Fix the bug with class intersection in the 'classes' and 'test-classes' folders. Both folders should contain different unique classes. In other words, we should avoid duplicating class compilation for tests. The problem with duplicated sources in tests was fixed: <a href="https://github.com/objectionary/eo/pull/2076">here<a/> But we still have problems with duplicated classes downloaded from dependencies. Apparently, we might check ResolveMojo to find the problem cause. Once the bug is fixed, uncomment the following statement.
eo-maven-plugin/src/it/duplicate_classes/verify.groovyrultorme@rultor.com2094208590DEV2085-f2fb287e21-27
Add GitHub action step to create an issue. It would be convenient to add github action step that will create an issue in case of any of the tests is failed. We can do it through <a href="https://github.com/JasonEtco/create-an-issue">create-an-issue</a> action. Also, you can read about that problem in that discussion: <a href="https://github.com/orgs/community/discussions/25111"> Create an issue case the workflow fails</a>
.github/workflows/daily.yml@yegor256yegor256@gmail.com2096189030DEV1890-dcbd8a3126-30
Change the behaviour of conversions for names with underscore. Currently, the conversion is done by replacing underscore with doubled underscore. We need to find more elegant solution. For example, we can use camel case for names with underscore. For example, we can convert `foo_bar` to `fooBar`. Or something else.
eo-maven-plugin/src/main/resources/org/eolang/maven/pre/to-java.xslrultorme@rultor.com2101209930DEV2099-8fd7aa3351-58
The test here is disabled, because it doesn't work together with LogFormatTest, for some pretty weird reason. We need to investigate why and fix it. The test itself is correct. Moreover, it doesn't need the SAME_THREAD annotation, because StdIo and WritesStdIo already provide thread safety, according to their documentation. However, removing this annotation from this test and LogFormatTest leads to an error even if just one of them is executed. This is also weird and needs investigation.
eo-maven-plugin/src/test/java/org/eolang/maven/SafeMojoTest.javaYegor Bugayenkoyegor256@gmail.com2141213190DEV2131-141dc86036-40
Remove redundant objects and levels. It's better to remove redundant objects from the result code snippet. They create some problems in the future transformations. When the transformation is fixed we can enable the test. The test should convert the code from the snippet to the next:
eo-parser/src/test/resources/org/eolang/parser/packs/optimize/redundant-levels.yaml@rultorme@rultor.com214279330DEV793-8a8388e4437-445
To enable next 4 as-bytes tests. All of the next 4 tests checks as-string, as-float, as-int and as-bool for transparency. All of these tests must be transparent and not create new object. For now it they are not and these tests are disabled. Looks like we need to store bytes in some place(like string pool in Java) and every time before creating a new object check if it already exists in the pool. If it does, return it from the pool, otherwise create a new one and put it into the pool. This way we will have only one instance of bytes for each value.
eo-runtime/src/test/eo/org/eolang/bytes-tests.eo@rultorme@rultor.com2146214430DEV2144-9604f975280-284
Enable RuleAllTestsHaveProductionClass rule. It is disabled in the whole eo-runtime module because it requires lots of fixes simultaneously. We have to enable that rule and apply all required changes in order to make all jtcop checks to pass.
eo-runtime/pom.xml@volodya-lombrozovolodya.lombrozo@gmail.com2171214630DEV2146-8bcd793d43-47
Remove RuleAllTestsHaveProductionClass suppressing. This rule was suppressed because the test class is generated and jtcop can't find it in the classpath. So, when that feature will be implemented in the jtcop, we have to remove all the similar suppression's from that test package. jtcop issue: https://github.com/volodya-lombrozo/jtcop/issues/178
eo-runtime/src/test/java/EOorg/EOeolang/EOboolEOnotTest.java@rultorme@rultor.com2297217130DEV2171-74d15acf348-352
Enable RuleAssertionMessage. This rule is disabled because lots of tests in the project are written without assertion messages. We have to add all messages for all assertions and then enable that rule and remove that puzzle.
pom.xmlrultorme@rultor.com3130229760DEV2297-97b6e95d54-57
Replace all appearances of {@link BinarizeParseTest#TO_ADD_MESSAGE} field in eo-maven-plugin with meaningful assert messages. Don't forget to remove {@link BinarizeParseTest#TO_ADD_MESSAGE} field and remove public modifier from this class if no longer need.
eo-maven-plugin/src/test/java/org/eolang/maven/BinarizeParseTest.javarultorme@rultor.com3131229760DEV2297-059cad7242-45
Replace all appearances of {@link EoIndentLexerTest#TO_ADD_MESSAGE} field in eo-parser with meaningful assert messages. Don't forget to remove {@link EoIndentLexerTest#TO_ADD_MESSAGE} field and remove public modifier from this class if no longer need.
eo-parser/src/test/java/org/eolang/parser/EoIndentLexerTest.javarultorme@rultor.com3132229760DEV2297-a38e794742-45
Replace all appearances of {@link AtCompositeTest#TO_ADD_MESSAGE} field in eo-runtime with meaningful assert messages. Don't forget to remove {@link AtCompositeTest#TO_ADD_MESSAGE} field and remove public modifier from this class if no longer need.
eo-runtime/src/test/java/org/eolang/AtCompositeTest.javarultorme@rultor.com3689229760DEV2297-a2270b4854-57
Replace all appearances of {@link CatalogsTest#TO_ADD_MESSAGE} field in eo-maven-plugin with meaningful assert messages. Don't forget to remove {@link CatalogsTest#TO_ADD_MESSAGE} field and remove public modifier from this class if no longer need.
eo-maven-plugin/src/test/java/org/eolang/maven/CatalogsTest.javaYegor Bugayenkoyegor256@gmail.com4240229760DEV2297-88eecc2f24-27
Replace all appearances of {@link PhCompositeTest#TO_ADD_MESSAGE} field in eo-runtime with meaningful assert messages. Don't forget to remove {@link PhCompositeTest#TO_ADD_MESSAGE} field and remove public modifier from this class if no longer need.
eo-runtime/src/test/java/org/eolang/PhCompositeTest.javaYegor Bugayenkoyegor256@gmail.com2147214430DEV2144-fc5d910c250-254
Enable RuleAllTestsHaveProductionClass rule. It is disabled in the whole eo-parser module because it requires lots of fixes simultaneously. We have to enable that rule and apply all required changes in order to make all jtcop checks to pass.
eo-parser/pom.xml@volodya-lombrozovolodya.lombrozo@gmail.com2148214430DEV2144-030a3222451-455
Enable RuleAllTestsHaveProductionClass rule. It is disabled in the whole eo-maven-plugin module because it requires lots of fixes simultaneously. We have to enable that rule and apply all required changes in order to make all jtcop checks to pass.
eo-maven-plugin/pom.xmlvolodya-lombrozovolodya.lombrozo@gmail.com2161210930DEV2109-949bde3168-72
Enable sparse-decoration.xsl transformation. Currently sparse-decoration.xsl transformations is disabled because it breaks some integration tests for unknown reason. Need to put the transformation right before warnings/unsorted-metas.xsl transformation and make sure build works.
eo-parser/src/main/java/org/eolang/parser/ParsingTrain.javarultorme@rultor.com2206216930DEV2169-f011871d255-259
Find the original cause of the problem with access denied. The problem is that sometimes we can't remove the file due to access denied. We need to find the original cause of the problem and fix it. Then, just remove AccessDeniedException from the catch block. For now, we just ignore the problem and log the warning.
eo-maven-plugin/src/main/java/org/eolang/maven/TranspileMojo.javarultorme@rultor.com2208219590DEV2195-24c0d5f149-51
Make cargo compilation in parallel. Now cargo projects are being built consistently which is too long. It is much better to build them in parallel to reduce time.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com221176130DEV761-525f7f4a32-38
Let's make sure memory can only accept one "type" of data primitives. If we try to write a float into a memory that was initialized with an int, we should get an error. The same goes for strings and booleans. We should also make sure that we can't write a string that is longer than the memory size. We should also make sure that we can't write a number that is bigger than the memory size. And etc. We can also implement memory in EO instead of Java and let it use ram object. Let's not forget to update the "Origins of Objects" paper.
eo-runtime/src/test/eo/org/eolang/memory-tests.eo@rultorme@rultor.com2434221130DEV2211-1a3ef3cb30-31
We can implement memory in EO instead of Java and let it use ram object. Let's not forget to update the "Origins of Objects" paper.
eo-runtime/src/main/eo/org/eolang/memory.eo@rultorme@rultor.com2435221130DEV2211-c8def9e644-51
Enable tests that uses memory object. After memory started behave like bytes some tests had been stopped worked. Need to refactor and enable disabled tests that uses memory object: malloc-return-error, complex-bool-expression-in-while, EOboolEOwhileTest.dataizesComplexBooleanToggle, EOboolEOwhileTest.loopsOverAbstractObjects, malloc-returns-different-pointers, mallocs-do-not-overlap, tuple-as-a-bound-attribute-size-2, iterates-over-simple-counter
eo-runtime/src/test/java/EOorg/EOeolang/EOmemoryTest.javarultorme@rultor.com2452243530DEV2435-00e0d12868-70
Enable test with array-each. assert-that.array-each object uses memory. So after changing memory behaviour array-each started to work incorrectly. Need to fix the object and then enable the test
eo-runtime/src/test/eo/org/eolang/tuple-tests.eo@maxonfjviponmtrunnikov@gmail.com2220221360DEV2213-8bc58d1c53-55
Create an instance of ForeignTojos in memory. It would be better to be able to create an instance of ForeignTojos in memory for test purposes.
eo-maven-plugin/src/test/java/org/eolang/maven/tojos/ForeignTojosTest.javarultorme@rultor.com2223219745DEV2197-52b4993f44-47
Update cached rust insert if it was changed. Now it copies cargo project to cache directory in the end of every compilation. It is better to copy the project only if it was changed with the last compilation.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.javarultorme@rultor.com2226160230DEV1602-b2f8e2db211-215
Use external tojos to implement object versioning. Implementation of object versioning will bring a lot significant changes. That's why it's better to use independent separated tojos for that purpose. At the end when object versioning works - just replace them and remove unnecessary one.
eo-maven-plugin/src/main/java/org/eolang/maven/SafeMojo.javarultorme@rultor.com2227160230DEV1602-f0cf7615473-478
Move the method to ForeignTojos if possible. Let's treat ForeignTojos as an object (not as a collection of data) and give it a chance to fulfill itself. It knows better how to do so. ForeignTojo in current implementation does not have method set() so we either need to implement it or just stay with the method here in FakeMaven class.
eo-maven-plugin/src/test/java/org/eolang/maven/FakeMaven.javarultorme@rultor.com2231223030DEV2230-f92ad9671-4
The test is skipped because it doesn't work. The syntax below is not supported, but it passes the test and no typos are detected. We should fix it. Most probably EOL-s are not detected at the end of objects correctly.
eo-parser/src/test/resources/org/eolang/parser/typos/broken-head.yamlYegor Bugayenkoyegor256@gmail.com2243224030DEV2240-ef806d5178-81
Test fails on github actions CI. On ubuntu 22.04 JARs of covert tool are downloaded from <a href="http://public.yegor256.com/convert.zip"/>. Test seems to work locally but it fails on github actions.
eo-parser/src/test/java/org/eolang/parser/XMIRTest.javamaxonfjviponmtrunnikov@gmail.com2257223830DEV2238-ba23d43161-63
Specify directory for names via pom.xml.Now names map is serialized in targetDir.toPath().getParent() which is a bad decision since it must be created just as target/names.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeParseMojo.javarultorme@rultor.com2258160230DEV1602-46b0e5d9204-208
Remove the flag when objection versioned is implemented. The variable is used for implementation of object versioning. It allows to use external tojos instead of foreign in Mojos. for the test purposes. When object versioning is implemented there will be no need for that variable
eo-maven-plugin/src/main/java/org/eolang/maven/SafeMojo.javarultorme@rultor.com2259160230DEV1602-59e4ff34128-134
Simplify xpath. Current implementation for building xpath with and without versions is quite ugly. For some reason if we try to take `/concat(@base,'|',@ver)` and there are object without attribute `ver` - xpath returns nothing. So we need to take `/@base` from objects where attribute `ver` is not present in both cases and then if flag `withVersions` is `true` - take `concat(@base,'|',@ver)` from objects attribute `ver` is present.
eo-maven-plugin/src/main/java/org/eolang/maven/DiscoverMojo.javarultorme@rultor.com2266225930DEV2259-d6c8796f49-54
Enable discoversWithSeveralObjectsWithDifferentVersions test. The discoversWithSeveralObjectsWithDifferentVersions test is disabled because we have found a bug in jcabi-xml library. You can read more about the bug <a href="https://github.com/jcabi/jcabi-xml/issues/211">here</a> When the bug will be fixed, we have to enable discoversWithSeveralObjectsWithDifferentVersions test.
eo-maven-plugin/src/test/java/org/eolang/maven/DiscoverMojoTest.javarultorme@rultor.com2278226630DEV2266-814f3bb599-104
Use more convenient constructor for SaxonDocument. The current constructor for SaxonDocument is not convenient and requires a lot of code. It would be better to create SaxonDocument right from the file. When the related issue will be implemented in jcabi-xml (you can check the progress <a href="https://github.com/jcabi/jcabi-xml/issues/215">here</a>) We have to change the constructor for SaxonDocument in this class and remove that puzzle.
eo-maven-plugin/src/main/java/org/eolang/maven/DiscoverMojo.javarultorme@rultor.com2269160230DEV1602-a75def4c62-68
Handle tags that are not in available versions list. VersionsMojo goes right after OptimizeMojo and replaces all tags with comparable hashes. EO code may contains tags that are not in available versions list (see: <a href="https://home.objectionary.com/tags.txt"/>). We need to catch somehow such versions and throw an exception. Or we can place the VersionsMojo right after ParseMojo and create new xsl which is used on optimization step and caches such invalid tags.
eo-maven-plugin/src/main/java/org/eolang/maven/VersionsMojo.javarultorme@rultor.com2270160230DEV1602-d66ec8b538-42
Come up with a good name for the class. There are many things we want to say with the name of the class: 1) it's commit hashes 2) it's a text 3) it's loaded from the objectionary. The result name will be ObjectionaryCommitHashesText and it may look a bit verbose. Maybe it really does not but we should decide anyway.
eo-maven-plugin/src/main/java/org/eolang/maven/hash/CommitHashesText.javarultorme@rultor.com2271160230DEV1602-ebb101bb63-65
What is the reason for this exception swallowing and returning an empty string? Why can't we just escalate/rethrow it? Now it looks pretty weird/wrong.
eo-maven-plugin/src/main/java/org/eolang/maven/hash/CommitHashesText.javarultorme@rultor.com2272160230DEV1602-b90ceb4560-66
min Move the code to prestructor. Some developers think that we should keep our constructors as small as possible and move complex logic (like in this constructor) to special static method which is called "prestructor". (See <a href="https://github.com/objectionary/eo/issues/1729">here</a>) We should make a decision what logic we should always move to the prestructor and should we at all?
eo-maven-plugin/src/main/java/org/eolang/maven/hash/CommitHashesMap.javarultorme@rultor.com2280223745DEV2237-666058eb144-147
Implement finding by location. Name argument is something like "^.^.some-obj". This string must be splitted by '.' and then for every part it is necessary to call this.attr().get()
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2281160230DEV1602-cc321ad561-67
Don't rewrite parsed xmir. VersionsMojo is executed right after ParseMojo and rewrites {@code .xmir} files in "1-parse" directory. Maybe this is not quite right, because files after parsing should be untouched. We either should 1) create a new folder where files after executing VersionsMojo are stored 2) or find another way to catch wrong versions without touching files in "1-parse" directory 3) or just accept rewriting files in "1-parse" and don't do anything if is not really critical
eo-maven-plugin/src/main/java/org/eolang/maven/VersionsMojo.javarultorme@rultor.com2375228190DEV2281-bc29f0be255-259
Remove AccessDeniedException catch block from cleanUpClasses method. This catch block was added to prevent the build from failing when the file can't be deleted due to access denied. This is a temporary solution and should be removed when the root cause of the problem is found. See <a href="https://github.com/objectionary/eo/issues/2370">issue.</a>
eo-maven-plugin/src/main/java/org/eolang/maven/TranspileMojo.javavolodya-lombrozovolodya.lombrozo@gmail.com2390237590DEV2375-409ab48f262-267
Add concurrency tests for the TranspileMojo.cleanUpClasses method. We should be sure that the method works correctly in a concurrent environment. In order to do so we should add a test that will run the cleanUpClasses method in multiple threads and check that the method works correctly without exceptions. We can apply the same approach as mentioned in that post: <a href="https://www.yegor256.com/2018/03/27/how-to-test-thread-safety.html">Post</a>
eo-maven-plugin/src/main/java/org/eolang/maven/TranspileMojo.javarultorme@rultor.com2376228130DEV2281-493fd13a39-44
Implement OnVersioned class. This class should parse raw string into object name and hash from object name with semver version. In other words this class should replace the behavior of {@link org.eolang.maven.VersionsMojo} class. When this class is implemented, remove the {@link org.eolang.maven.VersionsMojo class}. Don't forget to add tests for this class.
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnVersioned.javavolodya-lombrozovolodya.lombrozo@gmail.com2381237690DEV2376-3d36c5d741-50
Remove VersionsMojo. It is not used anymore. Remove it and all its dependencies from all the places. We need to apply {@link OnVersioned} in {@link org.eolang.maven.DiscoverMojo} and replace all the tests from VersionsMojoTest to DiscoverMojoTest. Also we need to enable the next tests: - {@link org.eolang.maven.ProbeMojoTest#findsProbesWithVersionsInDifferentObjectionaries()} - {@link org.eolang.maven.PullMojoTest#pullsProbedVersionedObjectsFromDifferentObjectionaries()} - {@link org.eolang.maven.DiscoverMojoTest#discoversWithSeveralObjectsWithDifferentVersions()} - {@link org.eolang.maven.DiscoverMojoTest#discoversWithVersions()} Don't forget to remove that puzzle after all.
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnVersioned.javarultorme@rultor.com2389238130DEV2381-b6d409bc33-38
Rename OnDefault and OnVersioned objects. Both seems misleading: OnVersioned replaces tag in given object with hash, OnDefault checks if given object contains version and if not - put the default one. It seems the names of the objects don't match with their behaviour. Suggestion: OnVersioned -> OnReplaced, OnDefault -> OnVersioned
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnDefault.javamaxonfjviponmtrunnikov@gmail.com2382237690DEV2376-007b3f6151-59
Frontend and backend delimiters differ. I was confused with the delimiter '#' that we use in {@link OnVersioned} and delimiter which we use in the frontend. For example: - "org.eolang.text|0.1.0" - frontend - "org.eolang.text#0.1.0" - backend The problem here is that we use the '|' delimiter on the frontend and '#' in the backend, but both of them mean the same thing - object name + version. I believe that we need to use the same symbol in both places, because it will be easier to understand the code. So, my suggestion to use '|' in both places.
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnVersioned.javarultorme@rultor.com2394237690DEV2376-11b4678841-49
Frontend and backend delimiters differ. I was confused with the delimiter '#' that we use in {@link OnReplaced} and delimiter which we use in the frontend. For example: - "org.eolang.text|0.1.0" - frontend - "org.eolang.text#0.1.0" - backend The problem here is that we use the '|' delimiter on the frontend and '#' in the backend, but both of them mean the same thing - object name + version. I believe that we need to use the same symbol in both places, because it will be easier to understand the code. So, my suggestion to use '|' in both places.
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnReplaced.javarultorme@rultor.com2420239430DEV2394-7c1cfda258-65
Hide static constant DELIMITER. We should hide static constant DELIMITER because it creates code duplication in many places. For example in {@link OnReplaced#split()} and {@link OnVersioned#split()} and {@link org.eolang.maven.Place#make(java.nio.file.Path, String)}. Apparently we have to create a class which will parse raw string into two parts value and optional version. Maybe this new class won't implement ObjectName interface. Why static fields are bad you can read here: - https://www.yegor256.com/2015/07/06/public-static-literals.html
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnReplaced.javarultorme@rultor.com2463239430DEV2394-92a7c10b58-66
Hide static constant DELIMITER. We should hide static constant DELIMITER because it creates code duplication in many places. For example in {@link OnReplaced#split()}, {@link OnVersioned#split()}, {@link OnDefault#split()} and {@link org.eolang.maven.Place#make(java.nio.file.Path, String)}. Apparently we have to create a class which will parse raw string into two parts value and optional version. Maybe this new class won't implement ObjectName interface. Why static fields are bad you can read here: - https://www.yegor256.com/2015/07/06/public-static-literals.html
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnReplaced.javarultorme@rultor.com2544246330DEV2463-ace772d149-54
Remove static constant DELIMITER. The static constant DELIMITER was hidden in the {@link DelimitedName} class and {@link OnReplaced} was switched to the new delimiting approach. Switch from DELIMITER to {@link DelimitedName} all the other classes, such as {@link OnVersioned}, {@link OnDefault} and {@link org.eolang.maven.Place#make(java.nio.file.Path, String)}.
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnReplaced.javarultorme@rultor.com2282160230DEV1602-f8cc6ecc67-71
Map with full hashes. Having done map with narrow hashes we got the situation where we can't get full hashes back in a simple way. We will actually need full hashes in ProbeMojo and PullMojo. So in order to avoid problems it would be better not to cut hashes here but when necessary.
eo-maven-plugin/src/main/java/org/eolang/maven/hash/CommitHashesMap.javarultorme@rultor.com2292223760DEV2237-4d09729278-80
Implement "dataize" method. It must call java dataizing method and get byte array from it. Then it have to return byte array as a result of dataization.
eo-runtime/src/main/rust/eo_env/src/eo_env.rs@rultorme@rultor.com2293223745DEV2237-e2051aed158-160
Implement the "put" method. Now it does nothing and created to check rust2java interaction. This method relates to building a new eo object in rust insert.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2294223745DEV2237-37351366171-173
Implement the "bind" method. It has tp put data to eo object by vertex. It does nothing now but it is called from rust via jni call_method function.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2295223745DEV2237-a32cd01f183-185
Implement the "copy" method. Now it does nothing and created to check rust2java interaction. This method relates to building a new eo object in rust insert.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2299160230DEV1602-d9e86093100-105
Use objectionaries to pull objects with different versions. Objects with different versions are stored in different storages (objectionaries). Every objectionary has its own hash. To pull versioned object from objectionary firstly we need to get right objectionary by object's version and then get object from that objectionary by name.
eo-maven-plugin/src/main/java/org/eolang/maven/PullMojo.javarultorme@rultor.com2352229930DEV2299-f07057b733-35
Do we really need the class? It seems it's used only for the test purposes but with last updates it is no longer of value. Also it assumes that any of its arguments may be null which is a doubtful design
eo-maven-plugin/src/main/java/org/eolang/maven/hash/ChCompound.javarultorme@rultor.com2300160230DEV1602-da3646cb61-64
Resolve code duplication. Probe and Pull mojos have several identical fields, methods and lines of code. Need to resolve this code duplication. One more abstract class is not an option. We can either join them into one mojo, or composite them inside other mojo.
eo-maven-plugin/src/main/java/org/eolang/maven/ProbeMojo.javarultorme@rultor.com2301160230DEV1602-046e303565-69
Add version to "probe" meta in xmir. To probe objects {@link ProbeMojo} gets object names from "probe" meta in xmir. Objects appear there after "add-probes.xsl" transformation. So to probe objects with versions in {@link ProbeMojo} we need to add information about these versions in xmir before the mojo.
eo-maven-plugin/src/main/java/org/eolang/maven/ProbeMojo.javarultorme@rultor.com2302160230DEV1602-73bdd8c0113-118
Use objectionaries to probe objects with different versions. Objects with different versions are stored in different storages (objectionaries). Every objectionary has its own hash. To get versioned object from objectionary firstly we need to get right objectionary by object's version and then get object from that objectionary by name.
eo-maven-plugin/src/main/java/org/eolang/maven/ProbeMojo.javarultorme@rultor.com2327230230DEV2302-7adb5af192-96
Rename the parameter "hash". This parameter is actually a tag, not a hash. By this tag application actually finds hash and then uses it. So need to rename this parameter to "tag" and rename it in all places where it's used. Also it would be better to use name "hash" for parameter "hsh" in {@link ProbeMojo} and {@link PullMojo}
eo-maven-plugin/src/main/java/org/eolang/maven/AssembleMojo.javarultorme@rultor.com2328230230DEV2302-25a30f7e55-61
Implement probing objects with versions and enable tests. ProbeMojo uses {@link Objectionaries} but it does not search for objects in different objectionaries. Need to implement searching objects in different objectionaries and enable disabled tests below: findsProbesWithVersionsInOneObjectionary, findsProbesWithVersionsInDifferentObjectionaries, findsProbesWithDefaultHash. Don't forget to remove this puzzle after that.
eo-maven-plugin/src/test/java/org/eolang/maven/ProbeMojoTest.javarultorme@rultor.com2339232830DEV2328-10f2c04d36-41
Inline code in {@code toString()} method. For some reason Codacy static analyzer fails on {@code toString()} method and says that "it's unnecessary to call toString() on String object". It does not understand that {@code this.swapped.value()} is not a String for some reason. Codacy checks only new added files, so need to inline that code when this file is already in the codebase.
eo-maven-plugin/src/main/java/org/eolang/maven/name/OnSwap.javarultorme@rultor.com2329230230DEV2302-4070538562-67
Add special method to {@link FakeMaven} for versioned program. On many compilation steps we test programs with versions and such programs looks similar or identical. We can create a separate method for it. Something like withVersionedProgram() See tests in {@link OptimizeMojoTest}, {@link VersionsMojoTest}, {@link DiscoverMojoTest}, {@link ProbeMojoTest}.
eo-maven-plugin/src/test/java/org/eolang/maven/ProbeMojoTest.javarultorme@rultor.com2330230230DEV2302-8638ac2968-69
Refactor tests in the class. Looks like there is a lot of code duplication among all tests in the class. Need to reduce it somehow.
eo-maven-plugin/src/test/java/org/eolang/maven/ProbeMojoTest.javarultorme@rultor.com2331230230DEV2302-4b0bd16e70-74
Refactor firstEntity method. The "first entity of the foreign tojos" looks strange. It looks like we are tying to scan an intermediate state which we are trying to read in the middle of the process. It lead to a fragile implementation. Could we check the result somehow else? Or to skip that check at all?
eo-maven-plugin/src/test/java/org/eolang/maven/ProbeMojoTest.javarultorme@rultor.com2392233190DEV2331-2e1725a8131-133
Add unit test for ForeignTojos.find method. The test should check that the method returns the tojo with the specified id. When the test is ready, remove that puzzle.
eo-maven-plugin/src/main/java/org/eolang/maven/tojos/ForeignTojos.javarultorme@rultor.com2313228390DEV2283-0094b89361-64
Create Universe class. Now its functionality is assigned to "EORust", which is why it is overcomplicated. "Universe" should perform a model of interaction with "eo" objects through methods "find", "put", "copy", "dataize" and "bind".
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2384231360DEV2313-a42edfae110-113
Implement the "dataize" method. It should dataize eo object by its vertex. This method is going to be called from rust insert and should not be static.
eo-runtime/src/main/java/org/eolang/Universe.javalevBagryansky28lev11@gmail.com2314228345DEV2283-27003227250-252
Implement handling of vertex returning. It must convert message array from 1 to last byte to the int and return eo object with corresponding vertex then.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2315228345DEV2283-ddadafec253-255
Implement handling of String returning. It must convert message array from 1 to last byte to the String and return eo object with converted String Data.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2322223960DEV2239-2a4796f239-41
min. Make this class extending Savable class. This class have save method and needs to have explanatory comment too via Commented class.
eo-maven-plugin/src/main/java/org/eolang/maven/rust/Cargo.javarultorme@rultor.com2335130730DEV1307-4a15f9bc48-58
Refactor and enable cage tests. Since object {@link EOcage} prohibit writing objects of different types to itself (for more information see <a href="https://github.com/objectionary/eo/issues/1307">the ticket</a>) some of its tests were disabled because they fail. Need to resolve them and enable. List of disabled tests: EOcageTest.overwritesCagedObject, EOcageTest.writesItselfToItself, avoid-infinite-loop, cage-nested-objects, avoid-infinite-loop-second-case, dataizes-encaged-object-lazily-first, calling-caged-function, dataizes-encaged-object-lazily-second, dataizes-encaged-object-lazily-third. infinite-loop-checkt, overwrites-caged-object-with-integer, rho-of-add-should-not-change, stores-abstract-object-into-cage, writes-into-cage.
eo-runtime/src/test/java/EOorg/EOeolang/EOcageTest.javarultorme@rultor.com2336130730DEV1307-e36f75dd44-50
Resolve flaky tests: 1) {@code savesToCache} on windows CI, see an example <a href="https://github.com/objectionary/eo/actions/runs/5713175702/job/ 15478085290?pr=2332">here</a> 2) {@code binarizesWithoutErrors}, see an example <a href="https://github.com/objectionary/eo/actions/runs/5713661855/job/ 15479445307?pr=2332">here</a>
eo-maven-plugin/src/test/java/org/eolang/maven/BinarizeMojoTest.javarultorme@rultor.com2373233690DEV2336-caedc47850-55
Enable all the tests in EOstdoutTest. The tests are disabled because they are flaky. The original issue is here: - https://github.com/objectionary/eo/issues/2371 When the issue is fixed, enable the tests and remove the @Disabled annotation. Don't forget to remove the puzzle itself.
eo-runtime/src/test/java/EOorg/EOeolang/EOio/EOstdoutTest.javarultorme@rultor.com2409169860DEV1698-d7ce48df62-66
Make up with an idea how to prevent StackOverflow exception or warn a user if he writes cage into the same cage. Options: 1) xsl file that somehow checks if cage is about to write to the same cage 2) catch StackOverflow exception at the top level and say to the user that maybe he writes cage to the same cage
eo-runtime/src/main/eo/org/eolang/cage.eo@rultorme@rultor.com2421160230DEV1602-5a03540635-40
After introducing this class we are able to use it instead of {@link ContainsFile} because we can pass varargs into constructor. So, the next step will be exactly that - we will just remove ContainsFile class (inline it into ContainsFiles) because we can do it, since we don't use ContainsFile anymore and the code will become smaller and simpler without redundant class.
eo-maven-plugin/src/test/java/org/eolang/maven/ContainsFiles.javamaxonfjviponmtrunnikov@gmail.com2422160230DEV1602-4a7b3be645-51
Create new object that will join two strings with "_". {@link Place} object makes a path for versioned objects using "_" as delimiter between name and hash. Here to test stored files after {@link AssembleMojo} execution "joinedWithUnderscore" function was introduced. So there's a code duplication and an ugly design. Need to create a new object that will join two strings with underscore and use it here and in {@link Place}.
eo-maven-plugin/src/test/java/org/eolang/maven/AssembleMojoTest.javamaxonfjviponmtrunnikov@gmail.com2743242260DEV2422-9365455c116-119
This test is unstable for now. We should resolve issues with unstable failures and only then enable the test. Also, see this <a href="https://github.com/objectionary/eo/issues/2727">issue</a>.
eo-maven-plugin/src/test/java/org/eolang/maven/OptimizeMojoTest.javarultorme@rultor.com2744242260DEV2422-ec85e51655-58
returnsFromCacheIfXmlAlreadyInCache: this test is unstable. We should resolve issues with unstable failures and only then enable the test. Also, see this <a href="https://github.com/objectionary/eo/issues/2727">issue</a>.
eo-maven-plugin/src/test/java/org/eolang/maven/optimization/OptCachedTest.javarultorme@rultor.com2423160230DEV1602-c4c0a1a152-54
Make up how to get rid of excessive usage of {@code ParseMojo.DIR}, {@code ResolveMojo.DIR} and so on. It would be nice to replace them with corresponding classes, or something similar
eo-maven-plugin/src/test/java/org/eolang/maven/AssembleMojoTest.javamaxonfjviponmtrunnikov@gmail.com2424160230DEV1602-0c5eb13b55-59
Refactor tests. Logic of AssembleMojo is to run several phases one-by-one in a loop. Nothing more. Everything else you are trying to check here is related to particular mojos (and we should check their behaviour in appropriate tests). In other words there are integration tests here. And, probably, it is not the best place for them.
eo-maven-plugin/src/test/java/org/eolang/maven/AssembleMojoTest.javamaxonfjviponmtrunnikov@gmail.com2443170830DEV1708-536ee55035-40
Implement VerifyMojo. VerifyMojo should check all errors and critical errors in xmir after {@link AssembleMojo} is finished. Also if {@code failOnWarning} flag is set to true - mojo should check warnings. When mojo is implemented - need to remove "failOnError" flag from {@link OptimizeMojo} and put "verify" step right after "assemble" in all pom.xml files
eo-maven-plugin/src/main/java/org/eolang/maven/VerifyMojo.javarultorme@rultor.com2678244390DEV2443-427f9946112-114
Remove the following failOnError flag. Now we have already got rid from it in {@link OptimizeMojo} and {@link VerifyMojo}. We need to make failOnError the behaviour default.
eo-maven-plugin/src/main/java/org/eolang/maven/AssembleMojo.java@rultorme@rultor.com2471244245DEV2442-a6fae75736-38
Add correct processing of the return value of functions. call_method returns Result<JValueOwned<'local>> which we should not just unwrap. We need to check it instead and return None if exception in java side happened.
eo-runtime/src/main/rust/eo_env/src/eo_env.rs@rultorme@rultor.com2472244245DEV2442-87b4ce00234-236
Improve handling EOError returning. It should also send a String message describing error on the native side and handle it correctly on the java side.
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.java@rultorme@rultor.com2481160230DEV1602-e06a1aef195-198
Remove the flag when objection versioned is implemented. The variable is used for implementation of object versioning. When object versioning is implemented there will be no need for that variable
eo-maven-plugin/src/main/java/org/eolang/maven/SafeMojo.javarultorme@rultor.com2482239930DEV2399-7063962a79-86
The test fails on GitHub Actions CI. Need to figure out what's the problem Stack trace: java.lang.IllegalArgumentException: Non-zero exit code 1: This is pdfTeX, Version 3.141592653-2.6-1.40.25 (T..4496..duced!Transcript written on article.log. at com.jcabi.log.VerboseProcess.stdout(VerboseProcess.java:298) at com.jcabi.log.VerboseProcess.stdout(VerboseProcess.java:185) at com.yegor256.Jaxec.execUnsafe(Jaxec.java:289) at com.yegor256.Jaxec.exec(Jaxec.java:258) at org.eolang.parser.XMIRTest.convertsAntlrToEbnf(XMIRTest.java:148)
eo-parser/src/test/java/org/eolang/parser/XMIRTest.javarultorme@rultor.com2483239930DEV2399-9c819bd6165-169
"idiomatic.eo" is not converted successfully. After introducing new grammar ({@see Program.g4}) example with name "idiomatic.eo" is not converted successfully in the test, so it was moved from {@see org.eolang.parser.xmir-samples} to {@see org.eolang.parser.xmir-samples-wrong}. Need to figure what's the problem and move it back to the origin folder.
eo-parser/src/test/java/org/eolang/parser/XMIRTest.javarultorme@rultor.com2484239930DEV2399-a6eaec3943-49
Do we need {@link RedundantParentheses} class? After refactoring grammar ({@see Program.g4}) parentheses are controlled at the level of grammar and can't be used in the many ways it was allowed to use them before. This is the reason the test is disabled. Need to check whether we really need the class with new grammar or not. If yes - return {@link RedundantParentheses} back to {@link XeListener} and refactor the test. If no - move the test cases below to {@link org.eolang.parser.typos} folder and remove {@link RedundantParentheses} class from the source code.
eo-parser/src/test/java/org/eolang/parser/RedundantParenthesesTest.javarultorme@rultor.com2515249730DEV2497-58e65091173-175
Uncomment infinites tests. For some reason times, plus, minus and div object of positive-infinity and negative-infinity causes flaky tests that mostly fail on CI/CD pipeline. Need to find a reason, fix it and uncomment all tests here and in positive-infinity-tests.eo file
eo-runtime/src/test/eo/org/eolang/negative-infinity-tests.eoMax Trunnikovmtrunnikov@gmail.com2516249830DEV2498-1c661137199-201
Enable the tests. After removing assert-that from eo-runtime $.string-starts-with it not allowed anymore. Need to refactor the next tests and enable them: - rust-bind-not-fails, - rust-error
eo-runtime/src/test/eo/org/eolang/rust-tests.eoMax Trunnikovmtrunnikov@gmail.com2539250630DEV2506-45cecde874-78
Replace hash with tag or remove it at all. This mojo should be executed on "deploy" phase and copy sources with dynamic hash. The hash should be taken from tag that is provided with command `mvn versions:set "-DnewVersion=${tag}"` which is executed before actual `mvn deploy`. Now for the test purposes we can specify deployHash from pom.xml but it should be remade or removed in the future.
eo-maven-plugin/src/main/java/org/eolang/maven/CopySourcesMojo.java@maxonfjviponmtrunnikov@gmail.com2541252830DEV2528-154f4f46102-105
Remove "master" pair from the table. Hash of "master" tag is not static and is being updated dynamically. That's why we should not use it in fake CommitHashesMap with {@link org.eolang.maven.objectionary.OyRemote}. That's why it would be better to remove it from the table and assure that all tests are green. Don't forget to remove the puzzle.
eo-maven-plugin/src/main/java/org/eolang/maven/hash/CommitHashesMap.javarultorme@rultor.com2543252830DEV2528-03b641f438-39
Add tests for {@link HmOptional}. It would be nice to test the functionality of the {@link HmOptional} class. Don't forget to remove the puzzle after introducing the tests.
eo-maven-plugin/src/main/java/org/eolang/maven/util/HmOptional.javarultorme@rultor.com2561255530DEV2555-d7532c61264-267
Enable integration tests. Integration tests were disabled because of new recursive implementation of tuple. Need to upload new version of eo-runtime to Objectionary and enable integration tests by just removing "maven-invoker-plugin" from this pom.xml. Don't forget to remove the puzzle.
eo-maven-plugin/pom.xml@maxonfjviponmtrunnikov@gmail.com2562255530DEV2555-1f303a3859-61
Enable the test. The test {@link SodgMojoTest#generatesSodgForPacks(String)} was disabled because it does not pass after changing tuple implementation. Need to refactor it and enable. Don't forget to remove the puzzle.
eo-maven-plugin/src/test/java/org/eolang/maven/SodgMojoTest.javamaxonfjviponmtrunnikov@gmail.com2563255530DEV2555-9082f5491-3
Enable the test. The test was disabled because it does not pass after changing tuple implementation. Need to refactor it and enable. Maybe it would be good to add several "stars-to-tuples.xsl" transformations to "xsls" section. Don't forget to remove the puzzle.
eo-maven-plugin/src/test/resources/org/eolang/maven/packs/pre/tuple-to-java.yamlmaxonfjviponmtrunnikov@gmail.com2564255530DEV2555-4368c3d1465-468
Enable the test when it's possible normalize object before application. Now this test does not work because we (arr.at 0).@ "returns" "if" from tuple.at which is wrong. Possibly we would need to extend EO syntax and phi calculus in order to be able to support such behavior.
eo-runtime/src/test/eo/org/eolang/runtime-tests.eomaxonfjviponmtrunnikov@gmail.com2565255530DEV2555-576d5948121-125
Enable rust tests when it's possible to get an abstract object from tuple. Many rust tests were disabled because "portal" inside EOrust stopped working because of new implementation of "tuple". Now it's not possible to put an abstract object into tuple and take it back. Need to enable the next tests when it's possible: rust-find-returns-int, rust-returns-vertex, rust-copy-not-fails, rust-dataize-not-fails, rust-plus, rust-bind-to-copy
eo-runtime/src/test/eo/org/eolang/rust-tests.eomaxonfjviponmtrunnikov@gmail.com2568256660DEV2566-db3f6d6c32-36
Remove AtComposite class. AtComposite duplicates the functionality of {@link AtLambda} and it's used only because the style of generated (from EO) java is imperative. We need to make transpilation declarative (for example new PhLocated(new PhWith(new PhMethod(...), ...), ...)) so we would not need AtComposite anymore. Don't forget to remove the puzzle.
eo-runtime/src/main/java/org/eolang/AtComposite.javamaxonfjviponmtrunnikov@gmail.com2572253630DEV2536-4ef7250833-36
We need to implement exec() method. The main idea is to read program written in EO and translate it to Phi-calculus. To store this result we suggest to create a new folder: xmir-to-phi. Let's store it to this folder one file by one.
eo-maven-plugin/src/main/java/org/eolang/maven/TranslateToPhiMojo.java@rultorme@rultor.com2573253530DEV2535-77ae0c2e37-41
Enable tests: {@link TranslateToPhiMojoTest#checksExistence(java.nio.file.Path)} and {@link TranslateToPhiMojoTest#checksPhiCalculusExpression(java.nio.file.Path)}. Also it's better to add more test cases in different EO programs with corresponding Phi-calculus expressions.
eo-maven-plugin/src/test/java/org/eolang/maven/TranslateToPhiMojoTest.javarultorme@rultor.com2579257730DEV2577-b57ee58e52-55
Resolve code duplication between {@link OptimizeMojo} and {@link ShakeMojo}. ShakeMojo was created in order to split two optimization stages: optimizations themselves and preparations for translation to java. Now these two mojo look almost the same and there's a lot of code duplication. So it's needed to resolve that. Don't forget to remove the puzzle
eo-maven-plugin/src/main/java/org/eolang/maven/ShakeMojo.java@rultorme@rultor.com2580257730DEV2577-d3715d4656-58
Add tests for ShakeMojo. ShakeMojo was created in order to split two optimization stages: optimizations themselves and preparations for translation to java Need to create tests for {@link ShakeMojo} in order to be sure that it does only it's job.
eo-maven-plugin/src/main/java/org/eolang/maven/ShakeMojo.javarultorme@rultor.com2584243730DEV2437-5c9f75e2411-415
Return previous values of the limits. Limits were changed after changing "explicit-data.xsl" and disabling some tests. Need to return limits back after tests are enabled. Previous values: INSTRUCTION.COVEREDRATIO - 0.70, LINE.COVEREDRATIO - 0.73, CLASS.MISSEDCOUNT - 6
eo-maven-plugin/pom.xml@rultorme@rultor.com2585243730DEV2437-ce30923445-47
Enable the tests: Some tests in the class were disabled after changing "explicit-data.xsl". Need to fix them and enable. Don't forget to remove the puzzle. Disabled tests: {@link BinarizeParseMojoTest#createsDependenciesSection(String)}.
eo-maven-plugin/src/test/java/org/eolang/maven/BinarizeParseMojoTest.javarultorme@rultor.com2586243730DEV2437-4800d65062-64
Enable the tests: Some tests in the class were disabled after changing "explicit-data.xsl". Need to fix them and enable. Don't forget to remove the puzzle. Disabled tests: {@link SodgMojoTest#generatesSodgForPacks(String)}.
eo-maven-plugin/src/test/java/org/eolang/maven/SodgMojoTest.javarultorme@rultor.com2587243760DEV2437-10dd7966137-145
Fix EOrust. After getting rid of delta attribute in data primitives EOrust stopped working. Reason - it can't find proper locator of "code" attribute because it's lost when it's wrapped with {@link org.eolang.PhCopy}. Need to figure out how to fix it and enable all disabled rust tests: rust-returns-negative-int, rust-returns-vertex, rust-invalid-put, rust-error, rust-returns-positive-int, rust-find-returns-int, rust-plus, rust-bind-not-fails, rust-is-string, rust-copy-not-fails, rust-is-byte-array, rust-bind-to-copy, rust-put-to-copy, rust-returns-positive-double, rust-returns-negative-double, rust-dataize-not-fails, UniverseDefaultTest#bindsCopyToAbstract, UniverseDefaultTest#putsToCopy,
eo-runtime/src/main/java/EOorg/EOeolang/EOrust.javarultorme@rultor.com2588243730DEV2437-58bda12f92-95
Change signature of the method. The method returns what's inside the delta attribute of the object. We got rid of delta attributes in data primitives so there's can be only bytes inside delta attribute. That's why this method will always actually return byte[]. Need to make a refactoring and make sure everything works fine.
eo-runtime/src/main/java/org/eolang/Dataized.javarultorme@rultor.com2589243730DEV2437-bddec9af77-80
Enable the test. After getting rid of delta attributes in data primitives this test started to execute infinitely long while other tests with "bool.while" are executed without any troubles. Need to find what's the problem and make the test enable again. Don't forget to remove the puzzle
eo-runtime/src/test/eo/org/eolang/bool-tests.eorultorme@rultor.com2590243730DEV2437-f38310c337-41
Enable the test {@link DataTest#printsString()}. The test was disabled because data primitives don't contain delta attribute anymore. So "toString" method would not return expected string. So there's a place where we need to decide either we don't expect such behaviour from data objects and then we can just remove the test; or we should change behaviour of "toString" method. Don't forget to remove the puzzle.
eo-runtime/src/test/java/org/eolang/DataTest.javarultorme@rultor.com2591243730DEV2437-d698a6db41-44
Enable the tests: {@link MainTest#deliversCleanOutput()} and {@link MainTest#executesJvmFullRun()}. These tests were disabled because we got rid of delta attribute in data primitives so code in the tests became invalid. Need to fix it and enable the tests. Don't forget to remove the puzzle.
eo-runtime/src/test/java/org/eolang/MainTest.javarultorme@rultor.com2645259160DEV2591-eade6066174-176
Make type casting when logging an app dataization result. The cast is necessary in this expression {@code new Dataized(app).take()} in order to correctly convert it to a string. This conversion it necessary for proper logging.
eo-runtime/src/main/java/org/eolang/Main.javarultorme@rultor.com2622261230DEV2612-0579c74965-69
Enable the test {@link AssembleMojoTest#assemblesTogetherWithVersions(Path)}. The test was disabled because varargs were removed in EO 0.34.0. So objects that are downloaded from older repositories are not parsed successfully because of the presence of varargs there. So we need to make 2-3 releases and then refactor the test with more fresh versions. Don't forget to remove the puzzle.
eo-maven-plugin/src/test/java/org/eolang/maven/AssembleMojoTest.javamaxonfjviponmtrunnikov@gmail.com2638257730DEV2577-73df16a845-48
Add tests for ShakeMojo. ShakeMojo was created in order to split two optimization stages: optimizations themselves and preparations for translation to java Need to create tests for {@link ShakeMojo} in order to be sure that it does only it's job. @since 0.33.0
eo-maven-plugin/src/main/java/org/eolang/maven/ShakeMojo.javaAlekseeva Yananeutronstar1996@gmail.com2648211890DEV2118-1bbacef752-54
Make it more generic. Perhaps by compilation of RustNode instead of going and building throw directories. Maybe it is better to get from BinarizeParseMojo.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeMojo.java@rultorme@rultor.com2649260990DEV2609-cb1cc596145-148
We can make the current class more generic by transferring this.addRust(input) snippet to corresponding FFINode- {@link RustNode}. We wanna make the class independent of ffi-insert as a result.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeParseMojo.java@rultorme@rultor.com2683264990DEV2649-2559f1c7148-154
This method may be more general. We need to get rid from rust dependencies in this method, because when adding another type of inserts it will be just copy-paste here. First of all, the for-loop must create all kinds of FFI nodes, not only {@link RustNode}. I think we can implement it, using something like {@code FFINodeFactory}, that will return appropriate FFI node for every XML node from {@code nodes}. Also it will be great to move paths to XML FFI insert nodes (such as {@code "/program/rusts/rust"}) from this method to a static class field.
eo-maven-plugin/src/main/java/org/eolang/maven/BinarizeParseMojo.java@rultorme@rultor.com2668240630DEV2406-a4a297dd73-79
Fix {@link FakeMaven#allowedParams(Class)} This function configures parameters of executed Mojo in {@link FakeMaven#execute(Class)} and parameters those Mojos which are inside this executed Mojo. If executed Mojo doesn't have parameters that are inside other Mojos, other Mojos parameters will not be configured. We need to make sure that custom parameters can be configured too. We need to enable the test {@link AssembleMojoTest#configuresChildParameters(Path)}.
eo-maven-plugin/src/test/java/org/eolang/maven/FakeMaven.javarultorme@rultor.com2670266530DEV2665-24cd76fe46-48
Check negative int bindings via xsl. It's possible now to make application with integer bindings like {@code x a:0 b:1}. Need to add xsl transformation that would check if such binding is negative and would add an error to "errors" section.
eo-parser/src/main/java/org/eolang/parser/ParsingTrain.javarultorme@rultor.com2674254690DEV2546-12d0794436-39
Add test that checks the message of exception in case of warning, error and critical in xmir. According to eo-parser/src/main/resources/org/eolang/parser/fail-on-critical.xsl it includes filename and line inside.
eo-maven-plugin/src/test/java/org/eolang/maven/VerifyMojoTest.javarultorme@rultor.com2746267430DEV2674-ddaefd4344-46
The function {@code OptCached.contains(final XML xml)} isn't work properly. This function compares caching and compilation times, which may lead to erroneous results. We need to fix this.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com2764274630DEV2746-c8b58fdb44-49
Use checksum, not time. The following tests show that fetching from the cache doesn't work correctly: - {@link OptCachedTest#returnsFromCacheCorrectProgram(Path path)}, - {@link OptCachedTest#returnsFromCacheButTimesSaveAndExecuteDifferent(Path path)}. Need to fix the file validation from cache: using checksum, but not time. Don't forget to enable the tests.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com2790274630DEV2746-9394bf6044-51
Fix caching mechanism in {@link OptCached}. Current The last modified time of the files between stages may be different, so it is not correct to do an equality comparison ({@code .equals(...)}). The last modification time of the file at the current stage must be less than or equal to the last modification time of file in cache at the next stage. The following tests show that fetching from the cache doesn't work correctly: - {@link OptCachedTest#returnsFromCacheCorrectProgram(Path path)}, - {@link OptCachedTest#returnsFromCacheButTimesSaveAndExecuteDifferent(Path path)}.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com2820279030DEV2790-ef16f78545-55
Refactor OptCache Class Currently, we have some concerns about the implementation of OptCache. It appears that the code is a bit too complicated. The OptCache class takes XMIR as an argument in OptCache#apply and the path to the same XMIR in the constructor, which seems odd. We need to consider how to refactor this class. Furthermore, the current implementation of OptCache and OptimizationTask has a similar logic of returning either from the cache or applying a default optimization. For more information, please refer to this discussion: <a href=“https://github.com/objectionary/eo/pull/2808#discussion_r1464941944”>issue</a>.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com2821279030DEV2790-b1dbe78659-69
There is repeating logic in tests. Code logic repeats in {@link OptCacedTest}, {@link OptimizeMojoTest.getAlreadyOptimizedResultsFromCache} and {@link ShakeMojoTest.getAlreadyShakenResultsFromCache}. To check whether a program is loaded from the cache, different tests use the same code { @code Files.setLastModifiedTime( res, FileTime.fromMillis(System.currentTimeMillis() + time) ); }. We need to think about how to remove this duplication.
eo-maven-plugin/src/test/java/org/eolang/maven/optimization/OptCachedTest.javarultorme@rultor.com2791274630DEV2746-ac77dd6852-56
Unify caching mechanism on stages: parse, optimize, pull and so on. Current implementations of caching on parsing stage and optimize stages work differently. In ParseMojo we have condition {@code if (tojo.hasHash()) }, in OptimizeMojo or ShakeMojo we compare creation time of files. Don't forget to enable the tests.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com2822274630DEV2746-0e77f2c440-44
Unify caching mechanism on stages: parse, optimize, pull and so on. Current implementations of caching on parsing stage and optimize stages work differently. In ParseMojo we have condition {@code if (tojo.hasHash())}, in OptimizeMojo or ShakeMojo we compare creation time of files. Don't forget to enable the tests.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptCached.javarultorme@rultor.com2747267430DEV2674-94c2148b46-51
The messages "Warnings identified" from /org/eolang/parser/fail-on-warnings.xsl can have nullable line number. Need fix it, that it works as in /org/eolang/parser/warnings/mandatory-version-meta.xsl and /org/eolang/parser/warnings/mandatory-home-meta.xsl. After you need fix {@code createRegEx()}.
eo-maven-plugin/src/test/java/org/eolang/maven/VerifyMojoTest.javarultorme@rultor.com2679240690DEV2406-424948df45-55
Make up with idea how to get rid of duplicate parameters between mojos. There's a situation where AssembleMojo owns, creates and executes other mojos, like {@link ParseMojo} or {@link OptimizeMojo}. When we configure our compiler via pom.xml maven tries to set parameters directly to the calling mojo. That's why we must to have all parameters from child mojos in AssembleMojo or {@link SafeMojo} (in order they won't be skipped and lost). That causes duplication of parameters between "parent" mojo and "child" mojos. Also it obliges the developer to remember that if he adds new parameter to some child mojo, this parameter must be present in parent mojo as well. We didn't find a way how we can resolve such duplication at the moment. So we need to either accept this as impossible to solve or resolve somehow. Anyway don't forget to remove the puzzle when the decision about the puzzle is made.
eo-maven-plugin/src/main/java/org/eolang/maven/AssembleMojo.java@rultorme@rultor.com2682264230DEV2642-02dbe2cd48-50
Create test packs for {@link UnphiMojo}. UnphiMojo seems to work correctly. We need to create yaml packs and enable {@link UnphiMojoTest#checksUnphiPacks(String, Path)} and make sure all of them are passed. Don't forget to remove the puzzle.
eo-maven-plugin/src/test/java/org/eolang/maven/UnphiMojoTest.javarultorme@rultor.com2700266030DEV2660-bfc86d4d59-62
Most of the snippets are disabled now, in the "src/test/resources/snippets/*.yaml" because they don't work. Hopefully, they will work once a new eo-runtime.jar is released. Just wait until it's released and try to enable the tests.
eo-maven-plugin/src/test/java/org/eolang/maven/it/SnippetTestCase.javaYegor Bugayenkoyegor256@gmail.com2702268430DEV2684-ebc6ed9431-34
Remove dependencies from eo-runtime. eo-runtime must stay clear out of any dependencies except those that are used in tests. It's needed to remove all such dependencies and include 'check-runtime-deps.groovy' test (which is failing for now) into 'tests' list. We also need to add "test" scope for all dependencies in pom.xml.
eo-runtime/src/test/groovy/verify.groovymaxonfjviponmtrunnikov@gmail.com2717266030DEV2660-a4091a35279-282
Enable the following integration tests when it's possible. Now they don't work because many .eo files are absent in the objectionary/home repository. Once they are released, the tests should work as is, without any modifications.
eo-maven-plugin/pom.xml@yegor256yegor256@gmail.com2718266030DEV2660-9f480ea058-62
One snippet is disabled now, in the "src/test/resources/snippets/*.yaml" because it doesn't work. I don't understand what's wrong with it (parenting.yaml). Let's try to find out and enable it (by removing the "skip" attribute from the YAML file).
eo-maven-plugin/src/test/java/org/eolang/maven/it/SnippetTestCase.javaYegor Bugayenkoyegor256@gmail.com2723271830DEV2718-833aa63643-48
Enable the tests. Tests {@link MainTest#deliversCleanOutput()} and {@link MainTest#executesJvmFullRun()} were disabled because they execute "org.eolang.io.stdout" object that accepts "string". But arguments after "org.eolang.io.stdout" are stored into "tuple" and are being passed as "tuple" object. And here we get the situation where "stdout" accepts "tuple" and fails. We need to enable the test by finding object that accepts "tuple" as the first argument, or make a custom one.
eo-runtime/src/test/java/org/eolang/MainTest.javarultorme@rultor.com2849271830DEV2718-585b9a2960-64
One snippet is disabled now, in the "src/test/resources/snippets/*.yaml" because there's no "sprintf" object in objectionary (fibo.yaml). When "sprintf" is in objectionary again - we need to enable it (by removing the "skip" attribute from the YAML file).
eo-runtime/src/test/java/org/eolang/SnippetTestCase.javarultorme@rultor.com2964271830DEV2718-9c8d799461-67
Two snippets are disabled now, in the "src/test/resources/snippets/*.yaml". The first needs "sprintf" object in objectionary (fibo.yaml). When "sprintf" is in objectionary again - we need to enable it (by removing the "skip" attribute from the YAML file). The second fails with "stackOverflow" exception. Maybe we just need to increase stack size in snippet tests.
eo-runtime/src/test/java/org/eolang/SnippetTestCase.javarultorme@rultor.com2985271830DEV2718-91412c5061-65
One snippets is disabled now, in the "src/test/resources/snippets/*.yaml". It needs "sprintf" object in objectionary (fibo.yaml). When "sprintf" is in objectionary again - we need to enable it (by removing the "skip" attribute from the YAML file).
eo-runtime/src/test/java/org/eolang/SnippetTestCase.javamaxonfjviponmtrunnikov@gmail.com2736252630DEV2526-e161ffc71-5
Enable the test when it's possible. Such syntax is invalid - scope braces should not be placed on different lines. It happens because of the next sequence of rules: scopeExtended -> happlicationExtended -> happlicationHeadExtended -> vmethod. The sequence allows using of vertical method in the head of scoped horizontal application. It should not be legal. Don't forget to remove the puzzle.
eo-parser/src/test/resources/org/eolang/parser/typos/vertical-method-in-scope.yamlrultorme@rultor.com2806273630DEV2736-686491961-4
Enable the test when it's possible. Such syntax is invalid - we can't use horizontal method after vertical method. If we decide that we allow such syntax we should add "vmethod" to "hmethodHeadExtended" rule and resolve left recursion violation. Don't forget to remove the puzzle
eo-parser/src/test/resources/org/eolang/parser/packs/syntax/hmethod-after-vmethod.yamlrultorme@rultor.com2737272960DEV2729-a3e8db241-6
Enable the test when it's possible. Current syntax is not supported now. In our EBNF such is understood as vertical application with 3 arguments. But all arguments in application must be either all bound or not. But it should not be like that with reversed application. Need to extend the grammar and make sure the test works. Test UnphiMojoTest#convertsValidXmirAndParsableEO also does not work because of this. Don't forget to remove the puzzle.
eo-parser/src/test/resources/org/eolang/parser/packs/syntax/binded-reversed-application.yamlrultorme@rultor.com2750272930DEV2729-2c784c2449-54
Xmir samples are not converted successfully. Since we have data only in bytes and after changing 'xmir-to-eo.xsl' many test are not passed anymore. The reason is next: if we have an integer in EO, it's converted to bytes in xmir, then it's converted to bytes in EO. Here we loose information about an integer while program still works the same. Need to either resolve such loosing or just rewrite the test. Previous samples were moved from "org/eolang/parser/xmir-samples" directory to "org/eolang/parser/xmir-samples-wrong"
eo-parser/src/test/java/org/eolang/parser/XMIRTest.javamaxonfjviponmtrunnikov@gmail.com2779275030DEV2750-1a6a169780-82
After removing conversion from bytes to value from 'xmir-to-eo.xsl' this test fails. All logic related to bytes conversion was moved to {@link StUnhex} class. Need to fix or remove this test.
eo-parser/src/test/java/org/eolang/parser/StEoLoggedTest.javarultorme@rultor.com2780275030DEV2750-54cc3dad51-55
Empty bytes in EO ("--") are not converted successfully. The test `org/eolang/parser/xmir-samples-wrong/empty-bytes.eo` fails. Transformation `xmir-to-eo.xsl` need to be fixed. Don't forget to move `empty-bytes.eo` test from `org/eolang/parser/xmir-samples-wrong` to `org/eolang/parser/xmir-samples` after fixing `xmir-to-eo.xsl`.
eo-parser/src/test/java/org/eolang/parser/XMIRTest.javarultorme@rultor.com2786275830DEV2758-5cd83ce543-47
To test that PrintMojo prints EO in different notations depends on given flag. When {@link org.eolang.parser.xmir.XmirReversed} and {@link org.eolang.parser.xmir.Xmir.Default} work correctly and prints xmirs in corresponding notations we need to check that PrintMojo uses them correctly depends on given flag {@link PrintMojo#printReversed}.
eo-maven-plugin/src/test/java/org/eolang/maven/PrintMojoTest.java@maxonfjviponmtrunnikov@gmail.com2787275830DEV2758-623c133e52-56
Implement printing from XMIR to EO in strait notation (where method starts on the next line). It should be done via XSL which should be used in {@link Xmir.Default} object. The next disabled test shows that such implementation does not work now: {@link XmirTest#printsStrait(String)}
eo-parser/src/test/java/org/eolang/parser/xmir/XmirTest.javamaxonfjviponmtrunnikov@gmail.com2807266030DEV2660-113567e5271-275
Enable the following integration tests when it's possible. Now they don't work because many .eo files are absent in the objectionary/home repository or can't be successfully parsed because of the syntax changes. Once they are released, the tests should work as is, without any modifications.
eo-maven-plugin/pom.xml@rultorme@rultor.com2818278560DEV2785-8797cda9164-166
Enable this test. For some reason this test fails. The only difference between this test and `iterating-tuple-with-while-using-internal-iterator` is that this test uses external iterator inside instead of standard `i` from `while` body.
eo-runtime/src/test/eo/org/eolang/bool-tests.eorultorme@rultor.com2819243760DEV2437-a4438d7a221-223
Enable the test. For some reason this test fails. The only difference between this test and `iterating-tuple-with-while-without-body-multiple` is that in this test tuple consists of only one element.
eo-runtime/src/test/eo/org/eolang/bool-tests.eorultorme@rultor.com2825261030DEV2610-958596871-3
Enable the test when PhiMojo supports "copy" syntax. The test is disabled because PhiMojo does not support converting "copy" EO syntax to phi. Need to extend "xmir-to-phi.xsl" and enable the test. Don't forget to remove the puzzle
eo-maven-plugin/src/test/resources/org/eolang/maven/phi/copy.yamlrultorme@rultor.com283592190DEV921-d2d334ec51-59
Add comment validation. We need to make sure that mandatory comment before abstract object is: starts with a capital letter, ends with a dot, includes only ASCII printable characters (0x20-0x7f), is at least 64 characters long, is in Markdown. It can be done either in {@link XeEoListener#enterCommentMandatory(EoParser.CommentMandatoryContext)} method or {@link XeEoListener#exitCommentMandatory(EoParser.CommentMandatoryContext)} method. I would recommend not to throw an exception but to create a new warning in XMIR if comment is invalid. Pay attention that whole eo-runtime may not built successfully because there are so much code where we must have valid comments (at least 64 symbols length).
eo-parser/src/main/java/org/eolang/parser/XeEoListener.javarultorme@rultor.com2841283530DEV2835-fdd45ac652-58
Change severity on comments validation. Current severity on comments validation is "warning". We need to change it to "error" to prevent users from ignoring this type of error. But there's a pitfall - there are so many little toy abstract objects in EO tests which we don't really want to document. That's why we should not validate comments if there's "+junit" meta in program. Also "eo-runtime" does not fail on warning now because it's not well documented. After eo-runtime is documented well - we need to turn on "failOnWarning" trigger in pom.xml inside "eo-runtime.
eo-parser/src/main/java/org/eolang/parser/XeEoListener.javamaxonfjviponmtrunnikov@gmail.com2860284130DEV2841-24b89c0152-55
Change severity on comments validation. Current severity on comments validation is "warning". We need to change it to "error" to prevent users from ignoring this type of error. But firstly we have to make "eo-runtime" documented well. After it's done - we need to turn on "failOnWarning" trigger in pom.xml inside "eo-runtime.
eo-parser/src/main/java/org/eolang/parser/XeEoListener.javarultorme@rultor.com2836169860DEV1698-c720742262-66
Make up with an idea how to prevent StackOverflow exception or warn a user if he writes cage into the same cage. Options: 1) xsl file that somehow checks if cage is about to write to the same cage 2) catch StackOverflow exception at the top level and say to the user that maybe he writes cage to the same cage.
eo-runtime/src/main/eo/org/eolang/cage.eorultorme@rultor.com2890283660DEV2836-3ac29bfb33-35
Add a new parameter of recursion depth. This parameter should be set by user via pom.xml. We can make DATAIZING_CAGES a Map and count how many times the cage was met.
eo-runtime/src/main/java/org/eolang/PhTracedEnclosure.javaYegor Bugayenkoyegor256@gmail.com2896289030DEV2890-c492b9ca53-57
Fix this {@link VerifyMojoTest#detectsErrorsSuccessfully} flaky test and enable it. It failed in ci <a href="https://github.com/objectionary/eo/actions/runs/8041230784/job/21960239171?pr=2892">here</a> without providing the regex and message. Also may be it would be cleaner to fix error Assertion since now it is hard to get why it failed.
eo-maven-plugin/src/test/java/org/eolang/maven/VerifyMojoTest.javaYegor Bugayenkoyegor256@gmail.com3181289690DEV2896-621330ec45-50
Make '@CaptureLogs' thread-safe. 'Logs' should contain only messages related to the test. Currently, '@CaptureLogs' appends all messages that were logged via 'Logger' to 'Logs', so messages from other tests (run in parallel) are also included, which causes problems when tests are run in parallel.
eo-maven-plugin/src/test/java/org/eolang/maven/log/CaptureLogs.javarultorme@rultor.com2891283660DEV2836-88180ad736-38
Make the class thread safe. It has private static field which can be accessed from differ thread and is not thread safe. Needs to synchronize this field.
eo-runtime/src/main/java/org/eolang/PhTracedEnclosure.javaYegor Bugayenkoyegor256@gmail.com2837243730DEV2437-9d2cb92f84-87
Enable the test. After getting rid of delta attributes in data primitives this test started to execute infinitely long while other tests with "bool.while" are executed without any troubles. Need to find what's the problem and make the test enable again. Don't forget to remove the puzzle.
eo-runtime/src/test/eo/org/eolang/bool-tests.eorultorme@rultor.com2844256660DEV2566-ecbb098f32-35
Remove AtComposite class. AtComposite is used only because the style of generated (from EO) java is imperative. We need to make transpilation declarative (for example new PhLocated(new PhWith(new PhMethod(...), ...), ...)) so we would not need AtComposite anymore. Don't forget to remove the puzzle.
eo-runtime/src/main/java/org/eolang/AtComposite.javarultorme@rultor.com2866286430DEV2864-e97890741-3
Enable phi test pack. Current test pack is disabled because it fails on UnphiMojoTest#convertsToXmirAndBack because our Phi grammar (Phi.g4) does not support XI without dispatch (see line 77). We need to resolve it and enable test pack.
eo-maven-plugin/src/test/resources/org/eolang/maven/phi/as-phi.yamlmaxonfjviponmtrunnikov@gmail.com2948292130DEV2921-5e2fe8e526-27
Add check if there are atoms, but no +rt meta. It should be illegal. Don't forget to remove the puzzle.
eo-parser/src/main/resources/org/eolang/parser/errors/rt-without-atom.xslrultorme@rultor.com2965293130DEV2931-5be4756d48-52
Return previous optimizations for the object. The optimization was removed because it does not work with new rho logic. Please check previous version of the object and try to implement it again. Also we need to enable the tuple tests: at-without-checks-with-first-element, at-without-checks-with-last-element
eo-runtime/src/main/eo/org/eolang/tuple.eorultorme@rultor.com2966293130DEV2931-d3bfc98635-37
Class does not work properly. Also the does not have enough tests. We need to add more, at least for the next methods: toString(), φTerm(), copy(), put() and make sure that caching works properly.
eo-runtime/src/main/java/org/eolang/AtConst.javarultorme@rultor.com2967293130DEV2931-115b513a31-40
Decide if we need this class. Looks like this class is redundant. I believe it was introduced in the days when the {@link Phi} object has method "move" which changes \rho attribute. Now rho attribute is immutable and can't be "moved". So we have to to decide if we need this class anymore. The method {@link PhImmovable#attr(String)} looked like: Attr val = this.origin.attr(attr); if ("ρ".equals(attr)) { val = new AtFixed(val); return val; Now this code is not compilable, so it was changed.
eo-runtime/src/main/java/org/eolang/PhImmovable.javarultorme@rultor.com2968293130DEV2931-88ed55f130-37
Enable or remove bool tests. Object bool.while stopped working properly when \rho attribute became immutable. Need to either remove the tests or refactor and enable them. Tests: iterates-over-simple-counter, complex-bool-expression-in-while, last-while-dataization-object, while-without-last-dataization, last-while-dataization-object-with-false-condition, iterating-tuple-with-while-using-internal-iterator, iterating-tuple-with-while-using-external-iterator, iterating-tuple-with-while-without-body-multiple, iterating-tuple-with-while-without-body-single
eo-runtime/src/test/eo/org/eolang/bool-tests.eorultorme@rultor.com2969293130DEV2931-033a49dd30-33
Enable cage tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: infinite-loop-check, dataizes-encaged-object-lazily-third, dataizes-encaged-object-lazily-first
eo-runtime/src/test/eo/org/eolang/cage-tests.eorultorme@rultor.com2970293160DEV2931-6d2befff31-33
Enable goto tests. They were fully disabled because they don't work for some reason when \rho attribute became immutable. Need to find out what's wrong and enable all the tests.
eo-runtime/src/test/eo/org/eolang/goto-tests.eorultorme@rultor.com2971293130DEV2931-3ba5c57330-33
Enable heap tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: malloc-returns-different-pointers, malloc-return-error, increments-pointer, mallocs-do-not-overlap
eo-runtime/src/test/eo/org/eolang/heap-tests.eorultorme@rultor.com2972293130DEV2931-52c9f17031-34
Enable runtime tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: parent-in-vertical-notation, parent-in-horizontal-notation, iterates-over-sigma, refers-to-inner-vars-correctly, recursion-without-arguments, right-way-to-use-hierarchy,
eo-runtime/src/test/eo/org/eolang/runtime-tests.eorultorme@rultor.com2973293160DEV2931-ad3f15a529-31
Enable rust tests. They were fully disabled because they don't work for some reason when \rho attribute became immutable. Need to find out what's wrong and enable all the tests.
eo-runtime/src/test/eo/org/eolang/rust-tests.eorultorme@rultor.com2974293130DEV2931-a76712ab30-32
Enable try tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: try-memory-update
eo-runtime/src/test/eo/org/eolang/try-tests.eorultorme@rultor.com2975293130DEV2931-aaaff93e56-58
Resolve test {@link EOcageTest#evaluatesLazily}. This test stopped working after introducing new rho logic. Need to decide either we can remove the test or we can resolve it somehow.
eo-runtime/src/test/java/EOorg/EOeolang/EOcageTest.javarultorme@rultor.com2976293130DEV2931-acb3514053-55
Enable the test {@link EOstdoutTest#doesNotPrintTwiceOnFloatComparisonMethods}. The test was disabled after new rho logic was introduced and {@link org.eolang.PhConst} stopped working properly. Need to enable the test when it's possible.
eo-runtime/src/test/java/EOorg/EOeolang/EOio/EOstdoutTest.javarultorme@rultor.com2977293130DEV2931-945d1fe546-48
Decide what to do with test {@link EOmemoryTest#comparesOnFly}. The test was disabled because it does not pass after new rho logic was introduced. We need either to delete the test, or resolve it somehow
eo-runtime/src/test/java/EOorg/EOeolang/EOmemoryTest.javarultorme@rultor.com2978293130DEV2931-0831d4d943-44
Enable the disabled tests. The tests were disabled after \rho attribute became immutable. Need to find out what's going on and resolve the tests.
eo-runtime/src/test/java/org/eolang/DataizedTest.javarultorme@rultor.com2979293130DEV2931-021739d943-45
Enable all disabled test in the class. The tests were disabled because object tupled-stdout.eo was removed from eo-runtime tests because it wasn't working in CI. Need to refactor them and enable
eo-runtime/src/test/java/org/eolang/MainTest.javarultorme@rultor.com2980293160DEV2931-fce5e0d637-39
Enable disabled tests. The tests were disabled because they don't work properly when \rho became immutable. When {@link PhConst} and {@link AtConst} are fixed we need to refactor and enable the disabled tests in the test class.
eo-runtime/src/test/java/org/eolang/PhConstTest.javarultorme@rultor.com2981293130DEV2931-daec7a2235-37
Enable the test {@link PhMethodTest#calculatesPhiManyTimes}. The test was disabled after \rho attribute became immutable and something changed with attributes caching. Need to either remove the test or refactor and enable it.
eo-runtime/src/test/java/org/eolang/PhMethodTest.javarultorme@rultor.com2989284530DEV2845-bf760c3e36-41
Use this class to fake \rho attribute when {@link Attr#DELTA} is not an attribute but asset. To remove {@link Attr#DELTA} from attribute, we will need to introduce some {@link Phi} decorator, that would encapsulate origin phi ({@link EOorg.EOeolang.EObytes}) and data (sequence of bytes). But in such case attributes of {@link EOorg.EOeolang.EObytes} should know that their \rho should refer to this decorator, but not instance of {@link EOorg.EOeolang.EObytes}. Here we can use this {@link PhFakeRho}.
eo-runtime/src/main/java/org/eolang/PhFakeRho.javarultorme@rultor.com2999293130DEV2931-aac3141856-58
Enable the test {@link OptimizeMojoTest#checksPacks(String)}. The test was disabled because java generation (to-java.xsl) was changed. Need to change .yaml packs and enable the test.
eo-maven-plugin/src/test/java/org/eolang/maven/OptimizeMojoTest.javamaxonfjviponmtrunnikov@gmail.com3000293130DEV2931-910575b030-32
Current implementation of memory is wrong because it stores its data in its attribute. The right implementation would store the data in some global storage with access by some id. Need to implement it and enable all tests that use memory.
eo-runtime/src/main/eo/org/eolang/memory.eomaxonfjviponmtrunnikov@gmail.com3001293130DEV2931-0ee2db0230-32
Enable cage tests. The test were disabled because 1) most probably "EOseq" dataizes its lambda many times in PhDefault.attr method. 2) current implementation of cage is wrong. Need to enable the tests when it's possible.
eo-runtime/src/test/eo/org/eolang/cage-tests.eomaxonfjviponmtrunnikov@gmail.com3002293130DEV2931-7e7e24f430-33
Enable heap tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: malloc-returns-different-pointers, malloc-return-error, increments-pointer, mallocs-do-not-overlap, write-and-read-without-error
eo-runtime/src/test/eo/org/eolang/heap-tests.eomaxonfjviponmtrunnikov@gmail.com3055300230DEV3002-687bf80a31-33
Enable the test "nested-goto". The test is disabled because top level object (like int, float, goto; which & is package eolang) are not copied when taken. When it's fixed, id inside "go" object should generate new number every time. And "nested-goto" should work.
eo-runtime/src/test/eo/org/eolang/goto-tests.eorultorme@rultor.com3004293130DEV2931-73a24c2430-32
Enable the test calculates-fibonacci-number-with-recursion. The test was disabled because for some reason it executes endlessly. Need to find what's wrong and enable the test.
eo-runtime/src/test/eo/org/eolang/int-tests.eomaxonfjviponmtrunnikov@gmail.com3005293130DEV2931-9689d2b130-31
Enable memory tests. The tests were disabled because current implementation of memory is wrong. Need to enable the tests when it's fixed.
eo-runtime/src/test/eo/org/eolang/memory-tests.eomaxonfjviponmtrunnikov@gmail.com3006293130DEV2931-f14b83fe30-32
Enable ram tests. The tests were disabled because they stopped work after changing dispatch mechanism. Need to find what's going on and enable the tests: several-slices-ram, writes-integer-to-ram, intersection-writes-in-ram
eo-runtime/src/test/eo/org/eolang/ram-tests.eomaxonfjviponmtrunnikov@gmail.com3007293130DEV2931-21b6bf5f31-37
Enable runtime tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: parent-in-vertical-notation, parent-in-horizontal-notation, iterates-over-sigma, refers-to-inner-vars-correctly, recursion-without-arguments, right-way-to-use-hierarchy, calculates-only-once-BROKEN, directly-accesses-objects-from-standard-root, directly-accesses-objects-from-root, constant-defends-against-side-effects, makes-shallow-copy, calling-caged-function, standard-root-and-root, rho-of-add-should-not-change
eo-runtime/src/test/eo/org/eolang/runtime-tests.eomaxonfjviponmtrunnikov@gmail.com3008293130DEV2931-547e6f9329-31
Enable rust tests. The tests were disabled because they stopped work after changing attributes dispatch logic. Now every time we "take" attribute - it's copied. So rust is not working because of it anymore. Need to find out what's going on and enable the tests.
eo-runtime/src/test/eo/org/eolang/rust-tests.eomaxonfjviponmtrunnikov@gmail.com3009293130DEV2931-23de747130-33
Enable the tests. The tests are disabled because 1) most probably "EOseq" dataizes its "body" many times while executing "lambda()" function in PhDefault.java, 2) implementation of "memory" is wrong at the moment. Need to find out what's going on and enable the tests.
eo-runtime/src/test/eo/org/eolang/seq-tests.eomaxonfjviponmtrunnikov@gmail.com3010293130DEV2931-b54627eb30-32
Enable the test switch-with-all-false-cases. For some reason it fails with "Given index is out of tuple bounds". It seems comparison inside "switch" does not work properly Need to find out what's going on and enable the test.
eo-runtime/src/test/eo/org/eolang/switch-tests.eomaxonfjviponmtrunnikov@gmail.com3011293130DEV2931-5e65ee7f30-32
Enable the tests try-memory-update, try-memory-update-catch. The test were disabled because 1) "try" object dataizes body twice 2) implementation of "memory" is wrong. Need to fix it and enable the test.
eo-runtime/src/test/eo/org/eolang/try-tests.eomaxonfjviponmtrunnikov@gmail.com3012293130DEV2931-4190276f30-31
Enable while tests. The tests were disabled because they all use "memory" object that has wrong implementation at the moment. Need to enable the tests when "memory" is ready.
eo-runtime/src/test/eo/org/eolang/while-tests.eomaxonfjviponmtrunnikov@gmail.com3013293130DEV2931-606d29f854-57
Enable the tests {@link EOstdoutTest#doesNotPrintTwiceOnIntComparisonMethods} and {@link EOstdoutTest#doesNotPrintTwiceOnFloatComparisonMethods}. The tests were disabled after new rho logic was introduced working properly. Need to enable the tests when it's possible.
eo-runtime/src/test/java/EOorg/EOeolang/EOio/EOstdoutTest.javamaxonfjviponmtrunnikov@gmail.com3015293130DEV2931-86a23c6e39-41
Enable the tests. The tests were disabled because Universe can't find object. Most probably it's because {@link PhDefault#take(String, Phi)} method makes copy of object before returning. Need to find out what's going on and enable the tests
eo-runtime/src/test/java/org/eolang/UniverseDefaultTest.javamaxonfjviponmtrunnikov@gmail.com3021293130DEV2931-0ed69df131-34
Enable runtime tests. The tests were disabled because they stopped working when \rho attribute became immutable. Need to find out what's going on and enable them. Tests: refers-to-inner-vars-correctly, makes-shallow-copy, calling-caged-function, rho-of-add-should-not-change
eo-runtime/src/test/eo/org/eolang/runtime-tests.eorultorme@rultor.com3067293160DEV2931-58eca49241-47
Change the data storage architecture. Current implementation allows the presence of two methods for data manipulations: {@link Data#attach(byte[])} to set data and {@link Data#delta()} to get data; which does not seem to be object oriented. It also requires every object to have reserved place for possible injected data. In our case, every {@link PhDefault} has {@link PhDefault#data} variable. It would be much better to have this data only inside some decorator. The main difficulty here is - child attributes of decorated object should know that their \rho is decorated and contains data.
eo-runtime/src/main/java/org/eolang/Data.javarultorme@rultor.com3068293130DEV2931-cf3a843730-33
Enable the tests: dataizes-encaged-object-lazily-third and dataizes-encaged-object-not-lazily-first. The tests were disabled because current cage implementation is wrong (see: https://github.com/objectionary/eo/issues/3057). We need to enable them when cage is great again.
eo-runtime/src/test/eo/org/eolang/cage-tests.eorultorme@rultor.com3120311530DEV3115-d79bda1138-40
Return constant-folding.xsl when it's ready. This optimization was removed from the train because it's not really ready and works only with `bool` object which was removed. We need to make this optimization great again and add to the train.
eo-maven-plugin/src/main/java/org/eolang/maven/optimization/OptTrain.javarultorme@rultor.com3158312260DEV3122-0fa0248c40-43
Add "Reload" to the test CommitHashesTextTest#isThreadSafe when issue about "Reload" annotation will be solved. We need to reinitialize some static fields of the class before the test will be executed.
eo-maven-plugin/src/test/java/org/eolang/maven/hash/CommitHashesTextTest.javarultorme@rultor.com3162309230DEV3092-ad9ee9a7261-265
Remove filter with "rust-tests.eo". BinarizeMojo does not add rust dependencies to rust-tests after phi->unphi (see: <a href="https://github.com/objectionary/eo/issues/3145">this</a> for details). When it's resolved we need to remove the filter and make sure the snippet test {@link SnippetTestCase#runsTestsAfterPhiAndUnphi(Path)} still works.
eo-runtime/src/test/java/org/eolang/SnippetTestCase.javaMax Trunnikovmtrunnikov@gmail.com3176314730DEV3147-66cbc2c723-27
Make duplicate names catcher more powerful. This test pack is disabled now because names duplication is not caught here. It happens because of "duplicate-names.xsl" thinks that abstract objects in the tests are on the different levels. Syntactically they are, but semantically they're not. So we need to make this duplicate catcher more powerful, enable the test by removing "skip: true" line and make sure it works.
eo-parser/src/test/resources/org/eolang/parser/packs/catches/catches-conflict-with-auto-name.yamlmaxonfjviponmtrunnikov@gmail.com3238316060DEV3160-4ce0c9ff340-343
Enable PMD check for eo-runtime/src/main/java/EOorg package, excluding only those rules that cannot be resolved (PMD.PackageCase, PMD.AvoidDollarSigns). All the others PMD violations should be resolved.
eo-runtime/pom.xmlRoman Korostinskiy70313618+c71n93@users.noreply.github.com3239316090DEV3160-01d3ed7734-38
This class requires refactoring. As a result of refactoring you should remove {@code @SuppressWarnings("PMD.GodClass")} from this class and {@code @SuppressWarnings("PMD.CognitiveComplexity")} from {@link BytesOf#shift} method. You can check description of this rules here <a href="https://pmd.github.io/pmd/pmd_rules_java_design">pmd.github.io</a>
eo-runtime/src/main/java/org/eolang/BytesOf.javaRoman Korostinskiy70313618+c71n93@users.noreply.github.com3265323990DEV3239-50a22f3c33-36
Method {@link BytesOf#shift} should be refactored to get rid of {@code @SuppressWarnings("PMD.CognitiveComplexity")} warning. You can check description of this rules here <a href="https://pmd.github.io/pmd/pmd_rules_java_design">pmd.github.io</a>
eo-runtime/src/main/java/org/eolang/BytesRaw.javaYegor Bugayenkoyegor256@gmail.com3240316090DEV3160-edcd4ffd196-199
This method should be refactored because it has high cognitive complexity and other problems. All {@code @checkstyle} warnings suppression and {@code SuppressWarnings("PMD.WarningName")} annotations for this method should be removed as a result of refactoring.
eo-runtime/src/main/java/org/eolang/Data.javaRoman Korostinskiy70313618+c71n93@users.noreply.github.com3262325130DEV3251-7a787eb5208-211
The object does not work. After moving `list` object to eo-runtime this is the only method which does not work because it's quite hard to implement properly, especially after big changes in EO semantic. We need to get it done and write some tests for it.
eo-runtime/src/main/eo/org/eolang/structs/list.eoYegor Bugayenkoyegor256@gmail.com3266124990DEV1249-130f864927-28
Add link to corresponding xmir2xmir test here as documentation when such tests arrive. Such tests would describe xsl sense via example of input/output. -->
eo-maven-plugin/src/main/resources/org/eolang/maven/pre/align-test-classes.xslYegor Bugayenkoyegor256@gmail.com3267124990DEV1249-cbc24ee527-28
Create xmir2xmir tests. This tests should be represented in yaml file and contain xsls, input(xmir) and output(xmir) sections. Add link to corresponding xmir2xmir test here as documentation -->
eo-maven-plugin/src/main/resources/org/eolang/maven/pre/remove-high-level-inner-classes.xslYegor Bugayenkoyegor256@gmail.com3269325130DEV3251-6874868e105-112
Find a way to link hash code and index of key. Right now map is implemented as `tuple` of objects where every element is composition of three entities: hash, key and value. When we try to find an element in hash map by key (K1) we're calculating hash of K1 (H1) and trying to find the entity where `entity.hash` (H2) is equal to H1. This search is implemented by simple reducing initial hash map `tuple` and obviously slow - O(n). We need to find a way to get a right index of entity in hash map
eo-runtime/src/main/eo/org/eolang/structs/map.eoYegor Bugayenkoyegor256@gmail.com3277325130DEV3251-af1f04ef313-315
Implement text.replaced object. This object was an atom in eo-strings. Maybe there's a way to implement it in pure EO. Don't remember to write some tests when object is implemented.
eo-runtime/src/main/eo/org/eolang/txt/text.eoYegor Bugayenkoyegor256@gmail.com3298225190DEV2251-77d3746554-57
It is necessary to call {@link ThreadLocal#remove()} on {@link Dataized#LEVEL} variables to prevent memory leaks. We should either find a place where this variable can be removed, or, if this is not possible (see https://github.com/objectionary/eo/pull/1930), come up with another solution.
eo-runtime/src/main/java/org/eolang/Dataized.javaYegor Bugayenkoyegor256@gmail.com3299225190DEV2251-f49f0da164-67
It is necessary to call {@link ThreadLocal#remove()} on {@link Dataized#MAX_LEVEL} variables to prevent memory leaks. We should either find a place where this variable can be removed, or, if this is not possible (see https://github.com/objectionary/eo/pull/1930), come up with another solution.
eo-runtime/src/main/java/org/eolang/Dataized.javaYegor Bugayenkoyegor256@gmail.com3300225190DEV2251-4b006ee265-68
It is necessary to call {@link ThreadLocal#remove()} on {@link PhDefault#NESTING} to prevent memory leaks. We should either find a place where this variable can be removed, or, if this is not possible (see https://github.com/objectionary/eo/pull/1930), come up with another solution.
eo-runtime/src/main/java/org/eolang/PhDefault.javaYegor Bugayenkoyegor256@gmail.com3301225190DEV2251-bb889cd150-53
It is necessary to call {@link ThreadLocal#remove()} on {@link PhTraced#DATAIZING_CAGES} to prevent memory leaks. We should either find a place where this variable can be removed, or, if this is not possible (see https://github.com/objectionary/eo/pull/1930), come up with another solution.
eo-runtime/src/main/java/org/eolang/PhTraced.javaYegor Bugayenkoyegor256@gmail.com3405325130DEV3251-9f4c4d8467-68
Enable the tests for windows. For some reason socket tests for windows are flaky. We need to deal with them somehow and enable.
eo-runtime/src/test/java/EOorg/EOeolang/EOnet/EOsocketTest.javaYegor Bugayenkoyegor256@gmail.com3483293160DEV2931-78329da540-46
Change the data storage architecture. Current implementation allows the presence of two methods for data manipulations: {@link Data#attach(byte[])} to set data and {@link Data#delta()} to get data; which does not seem to be object oriented. It also requires every object to have reserved place for possible injected data. In our case, every {@link PhDefault} has {@code PhDefault#data} variable. It would be much better to have this data only inside some decorator. The main difficulty here is - child attributes of decorated object should know that their \rho is decorated and contains data.
eo-runtime/src/main/java/org/eolang/Data.javaYegor Bugayenkoyegor256@gmail.com3524348330DEV3483-eeb6b45757-59
Enable the integration tests. {@link SnippetIT} and {@link PhiUnphiIT} were disabled because some break changes in eo-runtime were introduced. When new version of EO is released the tests must be enabled by removing {@code Assumptions.assumeTrue}.
eo-runtime/src/test/java/integration/SnippetIT.javaYegor Bugayenkoyegor256@gmail.com3600352930DEV3529-9b0a7ab064-66
Enable the Sodg packs. The next Sodg packs were disabled when we got rid of "abstract" attribute in XMIR: copy-of-abstract, copy-of-argument, dot-on-ref, nested-anonymous, rho, vars. We need to enable them and make sure they pass.
eo-maven-plugin/src/test/java/org/eolang/maven/SodgMojoTest.javaYegor Bugayenkoyegor256@gmail.com3601352930DEV3529-702b7a2067-69
Enable the test {@link SodgMojoTest#transformsThroughSheets}. The test was disabled when we got rid of "abstract" attribute in XMIR. We need to enable the test and make sure it works correctly.
eo-maven-plugin/src/test/java/org/eolang/maven/SodgMojoTest.javaYegor Bugayenkoyegor256@gmail.com3706333230DEV3332-e91c74c187-90
Add more specific error messages. Currently we write just "error: no viable alternative at input" for all errors. It's better to use 'Recognizer<?, ?> recognizer' parameter of the current method to retrieve more specific error messages.
eo-parser/src/main/java/org/eolang/parser/ParsingErrors.javaYegor Bugayenkoyegor256@gmail.com3714370630DEV3706-fc151a0d53-57
Fix the the name of the TAB token. Currently {@link EoIndentLexer} emits TAB token with the name 'ZERO' instead of 'TAB'. Fix the lexer to emit TAB token with the correct name. This problem affects lexer error messages. When this issue is fixed, remove the @Disabled annotation from the test.
eo-parser/src/test/java/org/eolang/parser/EoIndentLexerTest.javaYegor Bugayenkoyegor256@gmail.com3715370630DEV3706-d005da9672-76
Fix the the name of the UNTAB token. Currently {@link EoIndentLexer} emits UNTAB token with the name 'INT' instead of 'UNTAB'. Fix the lexer to emit UNTAB token with the correct name. This problem affects lexer error messages. When this issue is fixed, remove the @Disabled annotation from the test.
eo-parser/src/test/java/org/eolang/parser/EoIndentLexerTest.javaYegor Bugayenkoyegor256@gmail.com3742370630DEV3706-8f2012b649-52
Split {@link ParsingErrors} into two classes. Currently we use the same {@link ParsingErrors} class to accumulate all the parsing errors despite their origin. This class should be split into two classes: one for parsing errors {@link ParserErrors} and another for lexer errors {@link LexerErrors}.
eo-parser/src/main/java/org/eolang/parser/ParsingErrors.javaYegor Bugayenkoyegor256@gmail.com3743370630DEV3706-9d5eb2d724-26
Add exact location of the error in the message. This message is already quite clear, but it would be better if it included the exact location of the error.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/broken-binding.yamlYegor Bugayenkoyegor256@gmail.com3744370630DEV3706-4f05a2bf24-26
The error message doesn't highlight the exact position of the comment. The error message should be updated to point to the exact position of the comment.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/comment-in-method.yamlYegor Bugayenkoyegor256@gmail.com3828374430DEV3744-d585f4a674-77
Simplify {@link EoParserErrors#syntaxError} method. The method is too complex and has a high cognitive complexity. We need to simplify it. Don't forget to remove the @checkstyle CyclomaticComplexityCheck annotation and the @SuppressWarnings("PMD.CognitiveComplexity") annotation.
eo-parser/src/main/java/org/eolang/parser/EoParserErrors.javaYegor Bugayenkoyegor256@gmail.com3829374460DEV3744-555f5b8f24-26
Error Message Duplicates. As you can see, we have multiple error messages that are the same. We should remove duplicates and keep only meaningful error messages.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/two-spaces.yamlYegor Bugayenkoyegor256@gmail.com3745370630DEV3706-29423e3e24-27
Cryptic error message is returned Cryptic error message is returned when there are two empty lines between metas. The error message should be more informative and should highlight the exact location of the error.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/double-empty-lines.yamlYegor Bugayenkoyegor256@gmail.com3746370630DEV3706-fb7fb74124-28
Unreadable error message if program declaration is invalid. Improve error message for the case when a program declaration is invalid. The error message should be more informative and should point to the exact place in the input where the error occurred. Moreover it should be clear what to do to fix the error. 'simple-application-named.yaml' has the same issue.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/redundant-parentheses/simple-application.yamlYegor Bugayenkoyegor256@gmail.com3851370630DEV3706-5c197f9224-28
Unreadable error message if program declaration is invalid. Improve error message for the case when a program declaration is invalid. The error message should be more informative and should point to the exact place in the input where the error occurred. Moreover xml should be clear what to do to fix the error. 'simple-application-named.yaml' has the same issue.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/redundant-parentheses/simple-application.yamlYegor Bugayenkoyegor256@gmail.com3707333230DEV3332-fa5220a943-45
Add more decorators for the error message. For example, {@link ParsingErrors} currently contains logic related to the message formatting. It's better to create a separate class for this purpose.
eo-parser/src/main/java/org/eolang/parser/UnderlinedMessage.javaYegor Bugayenkoyegor256@gmail.com3756333230DEV3332-6fa7c07043-45
Add more decorators for the error message. For example, {@link GeneralErrors} currently contains logic related to the message formatting. It's better to create a separate class for this purpose.
eo-parser/src/main/java/org/eolang/parser/UnderlinedMessage.javaYegor Bugayenkoyegor256@gmail.com3782240690DEV2406-a7fa785a42-52
Make up with idea how to get rid of duplicate parameters between mojos. There's a situation where AssembleMojo owns, creates and executes other mojos, like {@link ParseMojo} or {@link ShakeMojo}. When we configure our compiler via pom.xml maven tries to set parameters directly to the calling mojo. That's why we must to have all parameters from child mojos in AssembleMojo or {@link SafeMojo} (in order they won't be skipped and lost). That causes duplication of parameters between "parent" mojo and "child" mojos. Also it obliges the developer to remember that if he adds new parameter to some child mojo, this parameter must be present in parent mojo as well. We didn't find a way how we can resolve such duplication at the moment. So we need to either accept this as impossible to solve or resolve somehow. Anyway don't forget to remove the puzzle when the decision about the puzzle is made.
eo-maven-plugin/src/main/java/org/eolang/maven/AssembleMojo.java@yegor256yegor256@gmail.com3804370830DEV3708-dc6420f754-56
Remove @Disabled annotation on {@code PhiMojoTest.usesCache()} and {@code PhiMojoTest.invalidatesCache()} when cache is implemented, check that tests is valid otherwise fix them.
eo-maven-plugin/src/test/java/org/eolang/maven/PhiMojoTest.javaYegor Bugayenkoyegor256@gmail.com3806370830DEV3708-52994f4a69-71
Remove @Disabled annotation on {@code UnphiMojoTest.usesCache()} and {@code UnphiMojoTest.invalidatesCache()} when cache is implemented, check that tests is valid otherwise fix them if needed.
eo-maven-plugin/src/test/java/org/eolang/maven/UnphiMojoTest.javaYegor Bugayenkoyegor256@gmail.com3814348130DEV3481-02ddf8e735-38
Remove all +unlit broken-ref from EO source code. These suppressions were added in order to be compile EO when @ref attribute from XMIR is removed, by it's checked by LintMojo. We need to remove these suppressions when `lints` repository is fixed and new version is used in EO.
eo-runtime/src/main/eo/org/eolang/txt/text.eoYegor Bugayenkoyegor256@gmail.com3815348130DEV3481-e9fa64ec43-46
Enable the test. The test was disabled because it's became a bit irrelevant when we got rid of @ref attributes and "abstract-float-up.xsl" transformation. We got a much less amount of generated classes after translation to java. So we need to refactor the test and enable it.
eo-runtime/src/test/java/org/eolang/XmirObjectTest.javaYegor Bugayenkoyegor256@gmail.com3869348130DEV3481-afe7d02639-42
Remove all +unlit metas from EO source code. These suppressions were added in order to be compile EO when @ref attribute from XMIR is removed, by it's checked by LintMojo. We need to remove these suppressions when `lints` repository is fixed and new version is used in EO.
eo-runtime/src/main/eo/org/eolang/txt/text.eoYegor Bugayenkoyegor256@gmail.com3965393435DEV3934-624dfb80260-263
Remove .without() from Program to enable `unknown-metas` and `unsorted-metas` lints. Currently we disabled them since lints does not support `+spdx` meta yet. Once <a href="https://github.com/objectionary/lints/issues/354">this</a> issue will be resolved, we should enable all lints.
eo-maven-plugin/src/main/java/org/eolang/maven/LintMojo.javaMax Trunnikovmtrunnikov@gmail.com3974364830DEV3648-8639da3622-26
Remove all `+unlint rt-without-atoms`, `+unlint empty-object` and `+unlit decorated-formation` metas from `eo-runtime`. These metas were added after we removed `@atom` attribute from XMIR. Now atoms have empty object with greek lambda as `@name` attribute. When these changes are fixed in `lints` repository we should update its version and remove all the possible `+unlint` metas.
eo-runtime/src/main/eo/org/eolang/try.eoYegor Bugayenkoyegor256@gmail.com3979397725DEV3977-b0b77e29262-265
Enable `unlint-non-existing-defect` lint. Currently its disabled because of <a href="https://github.com/objectionary/lints/issues/385">this</a> bug. Once issue will be resolved, we should enable this lint. Don't forget to enable this lint in WPA scope too.
eo-maven-plugin/src/main/java/org/eolang/maven/LintMojo.java@yegor256yegor256@gmail.com3999319930DEV3199-e3cbf62527-32
Enable PhiUnphiIT. The test was disabled because tuples are converted to EO incorrectly after phi-unphi. The key problem is recursive representation of tuples via tuple.with method. It should be done via simple application of tuple like it was done before, but with calculated length. Check the disabled org/eolang/parser/eo-packs/print/tuples-of-tuples-to-stars.yaml pack in eo-parser module.
eo-runtime/src/test/java/integration/PhiUnphiIT.javaYegor Bugayenkoyegor256@gmail.com4032380760DEV3807-d42fd5a24-10
XMIR format for bytes with data should be fixed. Current representation of org.eolang.bytes with data in XMIR is wrong, we miss one anonymous abstract object. When we add the missing anonymous abstract object, we should remove the `skip` property from this test. The same should be done for the test `bytes-in-number-with-anonymous-object.yaml` and `bytes-in-string-with-anonymous-object.yaml`.
eo-parser/src/test/resources/org/eolang/parser/eo-syntax/bytes-with-anonymous-object.yaml@yegor256yegor256@gmail.com4036403290DEV4032-7915ceda23-27
Remove the {@link StFlatBytes} usage from all the possible places. Currently we use this class to hide a problem with the XMIR of bytes. Some of the transformations were designed to work with the old XMIR format, where bytes were represented just as sequence of bytes within a 'Q.org.eolang.bytes' object. Now we have an abstract object that "wraps" the sequence of bytes.
eo-parser/src/main/java/org/eolang/parser/StFlatBytes.java@yegor256yegor256@gmail.com4039403630DEV4036-c4c6c9ca268-272
Ebable `object-has-data` lint. This lint doesn't work properly with the current implementation of bytes representation. We need to fix this lint and enable it. Check the progress of the issue <a href="https://github.com/objectionary/lints/issues/432">here</a>
eo-maven-plugin/src/main/java/org/eolang/maven/LintMojo.java@yegor256yegor256@gmail.com4065403930DEV4039-0979b15e276-280
Enable `inconsistent-args` lint. This lint generates many errors during the compilation of eo-runtime. We need to fix the errors in eo-runtime and enable this lint. Don't forget to enable this lint in {@link #lintAll(ConcurrentHashMap)} method as well.
eo-maven-plugin/src/main/java/org/eolang/maven/MjLint.java@yegor256yegor256@gmail.com4066403930DEV4039-be680e00313-318
Remove 'distinctByKey' method. We specifically added to the method to remove duplicates from the `defects` list generated by the {@link Program} class. There is the issue with duplicated error reports: https://github.com/objectionary/lints/issues/451 When this issue will be resolved, we should remove this method.
eo-maven-plugin/src/main/java/org/eolang/maven/MjLint.java@yegor256yegor256@gmail.com4040403690DEV4036-7af26ccb4-7
Repair 'inclusions' test for Sodg. We disabled this test because it was failing due new bytes representation with one extra abstract object. We need to fix the transformation and re-enable this test.
eo-maven-plugin/src/test/resources/org/eolang/maven/sodgs/inclusions.yaml@yegor256yegor256@gmail.com4042380790DEV3807-1446870580-85
Refactor EoSyntax transformations to make them less coupled. Currently most of these transformations are strongly coupled. For example, `stars-to-tuples`, `StHex` and `explicit-data` are dependent on each other. Moreover, the order of transformations matters. We need to refactor these transformations to make them more independent and order-agnostic if possible.
eo-parser/src/main/java/org/eolang/parser/EoSyntax.java@yegor256yegor256@gmail.com4043380790DEV3807-d56de9db86-91
Remove `explicit-data` transformation. we can try to remove explicit-data.xsl because we can generate the proper structure with data (with inner 'o' element) everywhere right away, without relaying on future transformations. This issue comes from this comment: https://github.com/objectionary/eo/pull/4041/files#r2014131951
eo-parser/src/main/java/org/eolang/parser/EoSyntax.javaYegor Bugayenkoyegor256@gmail.com4046352930DEV3529-de0949ce46-48
Enable the test {@link MjSodgTest#transformsThroughSheets}. The test was disabled when we got rid of "abstract" attribute in XMIR. We need to enable the test and make sure it works correctly.
eo-maven-plugin/src/test/java/org/eolang/maven/MjSodgTest.java@yegor256yegor256@gmail.com4052404930DEV4049-1efde77d29-33
Replace all occurrences of new XMLDocument().nodes() with new Xnav().path(). Right now we don't use {@link XMLDocument#nodes(String)} and {@link XMLDocument#xpath(String)} in production code, we got rid of it and replaced with {@link Xnav#path(String)} and {@link Xnav#element(String)}. But we didn't do it in the tests. Let's do it, it should increase the performance of our tests and make our code more consistent.
eo-maven-plugin/src/test/java/org/eolang/maven/MjLintTest.java@yegor256yegor256@gmail.com4213405235DEV4052-dcd5b33c45-49
Replace usage of XML.nodes() with Xnav.path(). For now, in {@link MjUnphiTest#checksUnphiPacks} we still use {@link XML#nodes(String)}, and cannot replace it with more faster alternative from Xnav, because of <a href="https://github.com/volodya-lombrozo/xnav/issues/118">this</a> issue. When it will be resolved, replace the usage to Xnav method.
eo-maven-plugin/src/test/java/org/eolang/maven/MjUnphiTest.javaYegor Bugayenkoyegor256@gmail.com4214405235DEV4052-bf7e56dd41-44
Replace XML.xpath() with Xnav.path(). Currently, in {@link EoSyntaxTest#checksTypoPacks} its blocked by attribute parsing issue in Xnav. Please check <a href="https://github.com/volodya-lombrozo/xnav/issues/119">this</a> issue for more details. Once it will be resolved, we should proceed with the replacement.
eo-parser/src/test/java/org/eolang/parser/EoSyntaxTest.javaYegor Bugayenkoyegor256@gmail.com4079373130DEV3731-87a797b83-8
Implement decorating for methods. Right now +decorate meta works only with objects which @base contains FQN, like `Q.org.eolang.string`. We get such @base when we write just `string` in EO and `add-default-package.xsl` appends `Q.org.eolang.` prefix to the @base. When we write `Q.org.eolang.string` in EO, it will look like sequence of applications of methods in XSL: `.string (.eolang (.org Q))`. In such case `decorate.xsl` does not work but it must. Don't forget to enable this pack and make sure it works
eo-parser/src/test/resources/org/eolang/parser/eo-packs/parse/decorate-fqn.yamlYegor Bugayenkoyegor256@gmail.com4094391930DEV3919-8ccccde335-39
Enable {@link MjLintTest} and {@link MjLintIT}. The tests were disabled because we've significantly changed the structure of XMIR. That's why all the lint cases in objectionary/lints don't catch defects properly anymore. We need to fix them first, then release a new version, then update it here, enable {@link MjLintTest} and set {@code skipLinting} flag in eo-runtime/pom.xml in qulice profile configuration to {@code false}.
eo-maven-plugin/src/test/java/org/eolang/maven/MjLintTest.java@yegor256yegor256@gmail.com4095391930DEV3919-523039ff30-32
Enable the tests for {@link StrictXmir}. The tests were disabled because XMIR.xsd was significantly changed and new version is not uploaded. When the new release of EO is made and new XMIR.xsd is uploaded - the tests should pass.
eo-parser/src/test/java/org/eolang/parser/StrictXmirTest.javaYegor Bugayenkoyegor256@gmail.com4126409660DEV4096-400bf40b29-31
Transpile object tree under test attribute into separate Java `*Test` class with the unit test to be run. Currently, we transpile all `o` into Java tests, while we should touch only newly introduced test attributes - (`o` with @name that starts with `+`).
eo-parser/src/main/java/org/eolang/parser/XeEoListener.javaYegor Bugayenkoyegor256@gmail.com4127409635DEV4096-07e9b33432-35
Handle name translation from test attribute starts with `+` to Java test method. Now, we receiving `invalid method declaration;` when compiling transpiled Java tests, so we need to adjust name translation. After this will be fixed, don't forget to move all EO tests from `eo-runtime` to new test syntax.
eo-parser/src/main/java/org/eolang/parser/XeEoListener.javaYegor Bugayenkoyegor256@gmail.com4151412745DEV4127-a516f4d427-30
Enable `runsAfterPhiAndUnphi` test after resolving `+` test syntax. For now, in EO test sources, when we use `+` syntax in test attributes, we getting `'no viable alternative at input 'org()↦⟦eolang()↦⟦foo()↦⟦foo-tests()↦⟦+''`. We should resolve it in PHI. Once it will be fixed, enable this test.
eo-runtime/src/test/java/integration/PhiUnphiIT.javaYegor Bugayenkoyegor256@gmail.com4155414835DEV4148-73985a42231-234
Enable `unused-void-attr` lint. We should enable this lint after the following issue with magic voids will be resolved: https://github.com/objectionary/lints/issues/574. Don't forget to enable `unused-void-attr` in the `test–compile` execution as well.
eo-runtime/pom.xml@yegor256yegor256@gmail.com4156414835DEV4148-01f6ad07238-241
Enable `duplicate-names-in-diff-context` lint. For now its too pedantic. See this: https://github.com/objectionary/lints/issues/578. Also, we should fix the bug with false positives with lambda object names in the atoms, in order to enable this lint.
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4157414835DEV4148-47fac486278-280
Enable `anonymous-formation` lint after required fixes. We should enable `anonymous-formation` lint, right after these issues will resolved in linter: https://github.com/objectionary/lints/issues/561, https://github.com/objectionary/lints/issues/562.
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4192415760DEV4157-b24a0abe245-249
Enable `redundant-object` lint after several fixes. Currently, it has multiple false-positives, that are reported here: https://github.com/objectionary/lints/issues/606, https://github.com/objectionary/lints/issues/607, and https://github.com/objectionary/lints/issues/609. After all of them will be fixed, we should enable lint. Don't forget to enable it in the `test-compile` execution too.
eo-runtime/pom.xml@yegor256yegor256@gmail.com4158414835DEV4148-c2bb5566286-288
Enable `inconsistent-args` lint after its adjustment. We should enable this lint after the issue with self object names will be resolved: https://github.com/objectionary/lints/issues/576.
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4197417630DEV4176-93c7a12624-28
Move EoMavenPlugin.java to eo-integration-tests Currently we have the duplicate between eo-runtime and eo-integration-tests modules. We should remove it by moving all the rest integration tests under eo-integration-tests module. Don't forget to remove "-exludes=**/EoMavenPlugin.java"
.github/workflows/simian.yml@yegor256yegor256@gmail.com4205419730DEV4197-ca5aa33a29-33
Enable JarIT test. The test is disabled because it requires EOorg.EOeolang.EOio Classes You can read about the issue <a href="https://github.com/objectionary/eo/issues/4203"> here </a> When it is fixed, please enable the test.
eo-integration-tests/src/test/java/integration/JarIT.java@yegor256yegor256@gmail.com4226420390DEV4203-eb15fbca30-34
Make {@link MjProbeTest} To Check Probes Currently, this test case only checks the number of probes found but does not verify the actual content of the probes. It would be beneficial to enhance this test to check the actual probes found.
eo-maven-plugin/src/test/java/org/eolang/maven/MjProbeTest.java@yegor256yegor256@gmail.com4238422630DEV4226-152da71629-32
Move {@link MjProbeTest#checksProbePacks(String)} to eo-runtime. This test checks the functionality related to the `eo-runtime` module only. There is no need to keep it in the `eo-maven-plugin` module since it doesn't touch the eo-maven-plugin functionality.
eo-maven-plugin/src/test/java/org/eolang/maven/MjProbeTest.java@yegor256yegor256@gmail.com4227420390DEV4203-8d91968a35-39
Enable {@link MjProbeTest#findsProbesInSimpleProgram(Path)} Test. This test is currently disabled because it fails. We should investigate the cause of the failure and enable the test. Originally this issue affected the integration tests, <a href="https://github.com/objectionary/eo/issues/4203">here</a>
eo-maven-plugin/src/test/java/org/eolang/maven/MjProbeTest.java@yegor256yegor256@gmail.com4232409645DEV4096-fbee93b814-17
Remove JUnit dependency from integration source run. Currently its needed because of `org.junit.jupiter.api.*"` imports, injected by the `to-java.xsl` during transpilation. Instead of hardcoding the JUnit import, we should place it only there, where we have test attributes.
eo-integration-tests/src/test/java/integration/EoSourceRun.java@yegor256yegor256@gmail.com4299423230DEV4232-4c7fc9d614-18
Conditionally add JUnit dependencies to integration tests. JUnit dependencies are needed for EO programs that contain test attributes (methods starting with '+'), but not for programs without tests. The XSL template now conditionally generates JUnit imports, but integration tests still need JUnit dependencies available when processing EO programs with tests.
eo-integration-tests/src/test/java/integration/EoSourceRun.java@yegor256yegor256@gmail.com4233409690DEV4096-fbd7f6ae193-196
Resolve code duplication for `tests` generation. Currently, we have a lot of code duplication in the templates that generate Java tests. They all are similar to the templates applied in the `java` element. Let's make them as generic as possible and reuse in both places.
eo-maven-plugin/src/main/resources/org/eolang/maven/transpile/to-java.xsl@yegor256yegor256@gmail.com4234409635DEV4096-c6f5a4ac255-258
Enable `sparse-decoration` lint. After we merged EO tests together with their source objects, and removed `+tests` meta, we have complains about sparse-decoration. Let's adjust and enable it.
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4235409690DEV4096-1fc1c1bc9-13
Merge tests for EO atoms together with their sources. Currently, we cannot move atom tests to their sources, because parser will fail to recognize them. Once it will be possible to have tests with the EO atom in the single file, then we should move the tests in it. Don't forget to move `runtime-tests.eo`, `try-tests.eo`, `txt/sscanf-tests.eo`, `txt/sprintf-tests.eo` too.
eo-runtime/src/main/eo/org/eolang/bool-tests.eoYegor Bugayenkoyegor256@gmail.com4263423535DEV4235-46fa6896309-312
Refactor MjTranspile.apply(). Now, it accepts too many parameters, let's decompose it into more manageable objects, that can be tested. Thus, we not only improve the situation in this class, but also improve the testability of the MjTranspile.
eo-maven-plugin/src/main/java/org/eolang/maven/MjTranspile.java@yegor256yegor256@gmail.com4264423560DEV4235-37ba631864-67
Allow atom to have only test attributes inside. Currently we allow to have just inners, while we should allow only test attributes inside the atom. For this, we need to intoduce new grammar rules. Don't forget to enable all the tests, related on not empty atoms.
eo-parser/src/main/antlr4/org/eolang/parser/Eo.g4@yegor256yegor256@gmail.com4318426445DEV4264-940f54546-10
Improve error message for atoms containing inners. For now we fail to report it properly. Current message contains: [5:-1] error: 'mismatched input 'UNTAB' expecting {'Q', 'QQ', '*', '$', '[', '(', '@', '^', '~', BYTES, STRING, INT, FLOAT, HEX, NAME, TEXT}'. We should improve, and verify it using `message` key in this YAML story. Also, check this issue: https://github.com/objectionary/eo/issues/4106.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/not-empty-atoms.yaml@yegor256yegor256@gmail.com4265423545DEV4235-f1975aa95-7
Enable test case for not empty atoms. In order to make this test passing, we need to update our Eo.g4 grammar to allow atoms have only test attributes inside, but not objects.
eo-parser/src/test/resources/org/eolang/parser/eo-typos/not-empty-atoms.yamlYegor Bugayenkoyegor256@gmail.com4266423535DEV4235-fabe62dd13-15
Move all tests from `runtime.eo` to other objects. For now runtime is just a set of runtime tests. Instead of having this, let's move its tests to the other objects, which tests are most suitable for.
eo-runtime/src/main/eo/org/eolang/runtime.eoYegor Bugayenkoyegor256@gmail.com4236409630DEV4096-477dc52a298-300
Enable tests-resolves-and-touches unit test. Now its disabled because of: "Can't #take("path"), the attribute is absent among other test 34 attrs. After we fix it, we should enable the test.
eo-runtime/src/main/eo/org/eolang/fs/file.eoYegor Bugayenkoyegor256@gmail.com4239420390DEV4203-3701a42823-27
Enable {@link ProbesTest#findsProbesInSimpleProgram()} Test. This test is currently disabled because it fails. We should investigate the cause of the failure and enable the test. Originally this issue affected the integration tests, <a href="https://github.com/objectionary/eo/issues/4203">here</a>
eo-maven-plugin/src/test/java/org/eolang/maven/ProbesTest.java@yegor256yegor256@gmail.com4241348030DEV3480-8a06dda432-35
Enable integration tests after new release 0.56.3 to Maven. Currently, integration tests fail because we are pulling eo-maven-plugin:0.56.2, which has org.eolang.Attr, which is removed now. Don't forget to enable {@link ReadmeSnippetsIT} too.
eo-integration-tests/src/test/java/integration/SnippetIT.java@yegor256yegor256@gmail.com4242348030DEV3480-6f27e03111-13
Move out `PhiWithRHo.origin()` method. Now we use it in {@link PhDefault#put(int, Phi)}. Let's move it to other class, in order to get rid of `TooManyMethods` PMD violation.
eo-runtime/src/main/java/org/eolang/PhWithRho.javaYegor Bugayenkoyegor256@gmail.com4243348045DEV3480-c54bfd0f103-106
Remove Phi.copy(Phi) method from the interface. Currently, we use this method in {@link PhDefault#copy()} in order to copy the attributes correctly. However, not all Phi implementations need this type of copying. It should be possible to remove this method, and use only {@link Phi#copy()}.
eo-runtime/src/main/java/org/eolang/Phi.javaYegor Bugayenkoyegor256@gmail.com4286426130DEV4261-e0ea2b8431-34
Enable MjLint tests after lints will migrate to the ObjectName implementation. Now, `lints` uses `org.eolang.parser.ObjectName` as class. Now its an interface, and `lints` should use {@link OnDefault} instead. Don't forget to enable lints in the {@link MjTranspileTest}, {@link MjLintIT} and `pom.xml` of `eo-runtime` as well.
eo-maven-plugin/src/test/java/org/eolang/maven/MjLintTest.java@yegor256yegor256@gmail.com4313414835DEV4148-d58c7884231-233
Enable `lintAsPackage` below and fix all warnings that will be reported (there will be many of them), so that we can enable it in the `test-compile` execution as well:
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4381436030DEV4360-3c6890da31-34
Enable `StrictXmir` tests after XMIR.xsd release. Now tests fail because the latest schema available <a href="https://www.eolang.org/XMIR.xsd">here</a> does not allow `@author` attribute in the `object` element. Let's enable the tests right after we release new version.
eo-parser/src/test/java/org/eolang/parser/StrictXmirTest.java@yegor256yegor256@gmail.com4428439435DEV4394-5825bf63226-234
Lints after fixing Phi dependent lints. For now, `unit-test-without-phi`, `redundant-object check` for `@` attribute in the tests, which represents Phi. However, we changed the notation in the XMIR, and now the same Phi represented as 'φ'. Don't forget to enable these lints, after new version of lints with the fix will be available. The lint `unlint-non-existing-defect` should be also enabled, but now disabled due to massive local unlints of `redundant-object` lint, which is currently disabled. We decided to skip linting entirely, not just skipping individual lints, because of this issue: https://github.com/objectionary/lints/issues/699.
eo-runtime/pom.xml@yegor256yegor256@gmail.com4442442660DEV4426-eb74c0575-25
Enable `auto-phi` after nested object representation in auto phi will be fixed. Currently, this snippet fails, because we have duplication in the generated representation of auto Phi object: application assigned to '@' (`ξ.ρ.m.get.eq` in this example) contains itself in the first as attribute `α0`, together with nested attribute - reference to void attribute (`ξ.i`). We must fix this nesting, and enable the test. This XMIR is problematic: <o line="10" name="a🌵108" pos="8"> <o base="∅" line="10" name="i" pos="24"/> <o base="ξ.ρ.m.get.eq" line="10" name="φ" pos="8"> <o as="α0" base="ξ.ρ.m.get.eq" line="10" pos="13"> <o as="α0" base="ξ.i" line="10"/> <o as="α1" base="Q.org.eolang.number" line="10" pos="17".../> </o> </o> </o> The correct XMIR should be this: <o line="10" name="a🌵108" pos="8"> <o base="∅" line="10" name="i" pos="24"/> <o base="ξ.ρ.m.get.eq" line="10" name="φ" pos="8"> <o as="α1" base="Q.org.eolang.number" line="10" pos="17".../> </o> </o>
eo-integration-tests/src/test/resources/org/eolang/snippets/auto-phi.yaml@yegor256yegor256@gmail.com4444442660DEV4426-0dc59b755-25
Enable `auto-phi` after nested object representation in auto phi will be fixed. Currently, this snippet fails, because we have duplication in the generated representation of auto Phi object: application assigned to '@' (`ξ.ρ.m.get.eq` in this example) contains itself in the first as attribute `α0`, together with nested attribute - reference to void attribute (`ξ.i`). We must fix this nesting, and enable the test. This XMIR is problematic: <o line="10" name="a🌵108" pos="8"> <o base="∅" line="10" name="i" pos="24"/> <o base="ξ.ρ.m.get.eq" line="10" name="φ" pos="8"> <o as="α0" base="ξ.ρ.m.get.eq" line="10" pos="13"> <o as="α0" base="ξ.i" line="10"/> <o as="α1" base="Φ.org.eolang.number" line="10" pos="17".../> </o> </o> </o> The correct XMIR should be this: <o line="10" name="a🌵108" pos="8"> <o base="∅" line="10" name="i" pos="24"/> <o base="ξ.ρ.m.get.eq" line="10" name="φ" pos="8"> <o as="α1" base="Φ.org.eolang.number" line="10" pos="17".../> </o> </o>
eo-integration-tests/src/test/resources/org/eolang/snippets/auto-phi.yaml@yegor256yegor256@gmail.com4557444490DEV4444-58b564238-12
Replace `ap🌵` with `a🌵` for Auto Phi formation names in XMIR. Currently, we use it in order to locate objects with `ap🌵` attribute, here, in this stylesheet. We should replace name with classic auto name attribute: `a🌵`, and, rewrite logic from this stylesheet to Java (in XeEoListener.java). This will lead to simplification of auto-phi formation processing on the parser level.
eo-parser/src/main/resources/org/eolang/parser/parse/auto-phi-formation-restruct.xsl@yegor256yegor256@gmail.com4445439435DEV4394-a43fc13625-35
Enable MjLints related tests after `lints` will be adjusted with `Φ` object. For now, lints checks for `Q` instead of `Φ`. After new version of lints released, we should enable these integration tests in MjLintIT, and others: {@link MjLintTest#doesNotFailWithNoErrorsAndWarnings}, {@link MjLintTest#doesNotDetectWarningWithoutCorrespondingFlag}, {@link MjLintTest#skipsAlreadyLinted}, {@link MjLintTest#savesVerifiedResultsToCache}, {@link MjTranspileTest#recompilesIfModified}, {@link MjTranspileTest#recompilesIfExpired}, {@link MjTranspileTest#doesNotRetranspileIfNotModified}, {@link MjTranspileTest#transpilesSimpleEoProgram}, {@link MjTranspileTest#transpilesSeveralEoProgramsInParallel}, {@link MjTranspileTest#transpilesSourcesForDifferentScopesWithoutIntersections}.
eo-maven-plugin/src/test/java/org/eolang/maven/MjLintIT.java@yegor256yegor256@gmail.com4458441135DEV4411-1af760bf88-92
Replace all left usages of `$ > oname`. We should remove all the usages like `$ > matched` from the syntax, and from the runtime objects. Currently, it is not possible because syntax sugar for object idempotency is not fully implemented, and we cannot remove some edge case usages, like here, in `matched`. Don't forget to remove this puzzle.
eo-runtime/src/main/eo/org/eolang/txt/regex.eoYegor Bugayenkoyegor256@gmail.com4489447535DEV4475-675c073e71-73
Enable `writes-larger-data-than-provided-block` test after resizing will be implemented. If the provided memory block is not large enough for the data to write, a runtime error happens, however we can use `malloc.of.allocated.resized` to increase the size of the block.
eo-runtime/src/main/eo/org/eolang/io/malloc-as-output.eoYegor Bugayenkoyegor256@gmail.com4576447535DEV4475-be0d3e3d71-73
Enable `writes-larger-data-than-provided-block` after resize will be implemented. If the provided memory block is not large enough for the data to write, a runtime error happens, however we can use `malloc.of.allocated.resized` to increase the size of the block.
eo-runtime/src/main/eo/org/eolang/io/malloc-as-output.eoYegor Bugayenkoyegor256@gmail.com4584447535DEV4475-c4f74bf071-73
Enable `writes-larger-data-than-provided-block` after resize will be implemented. If the provided memory block is not large enough for the data to write, a runtime error happens. However we can use `malloc.of.allocated.resized` to increase the size of the block.
eo-runtime/src/main/eo/org/eolang/io/malloc-as-output.eoYegor Bugayenkoyegor256@gmail.com4630453020DEV4530-b4741bf029-33
Enable JarIT#runsProgramFromJar after new EO package names will be released. Now, in test, we still trying to run it on previous package names: `sys`, `txt`, and so on, however, we refactored package names to be more compact: `sm`, `tt`, etc. Once it will be released, we must enable this test, it should pass. These tests should be enabled as well: `SnippetIT#runsAllSnippets`, `ReadmeSnippetsIT#validatesReadmeSnippets`.
eo-integration-tests/src/test/java/integration/JarIT.java@yegor256yegor256@gmail.com4672459530DEV4595-822bd2f930-32
Remove unnecessary methods and constructors related to dispatch by index from eo-runtime. In previous PR we removed supporting dispatch by index from eo-parser. Now we can safely remove all the unnecessary logic from eo-runtime.
eo-runtime/src/main/java/org/eolang/PhMethod.javaYegor Bugayenkoyegor256@gmail.com4679467330DEV4673-55e3cd9117-22
Replace all PhVoid occurrences with AtVoid when all other Attr classes are returned to eo-runtime. This class does not do anything useful right now, it is not used anywhere. The class is added as part of the task where Attr and its classes are returned to eo-runtime. When all other classes are returned - this class must replace PhVoid everywhere.
eo-runtime/src/main/java/org/eolang/AtVoid.javaYegor Bugayenkoyegor256@gmail.com4695467930DEV4679-dd4e56b233-36
Enable ReadmeSnippetsIT when it's possible. The test was disabled because because Attr interface was returned back and now these tests don't work anymore. These tests must be enabled when new EO release is made.
eo-integration-tests/src/test/java/integration/ReadmeSnippetsIT.java@yegor256yegor256@gmail.com4696467930DEV4679-021a53a732-35
Enable SnippetIT when it's possible. The test was disabled because because Attr interface was returned back and now these tests don't work anymore. These tests must be enabled when new EO release is made.
eo-integration-tests/src/test/java/integration/SnippetIT.java@yegor256yegor256@gmail.com4683467330DEV4673-8b3144e816-21
Replace all PhComposite occurrences with AtComposite when all other Attr classes are returned to eo-runtime. This class does not do anything useful right now, it is not used anywhere. The class is added as part of the task where Attr and its classes are returned to eo-runtime. When all other classes are returned - this class must replace PhComposite everywhere.
eo-runtime/src/main/java/org/eolang/AtComposite.javaRultor.comgpg@rultor.com4685467330DEV4673-eddbad5515-20
Replace all PhCached occurrences with AtOnce when all other Attr classes are returned to eo-runtime. This class does not do anything useful right now, it is not used anywhere. The class is added as part of the task where Attr and its classes are returned to eo-runtime. When all other classes are returned - this class must replace PhCached everywhere.
eo-runtime/src/main/java/org/eolang/AtOnce.javaEugene Sukharevr0bari@yandex.ru4687467330DEV4673-3980c27516-21
Replace all PhRho occurrences with AtRho when all other Attr classes are returned to eo-runtime. This class does not do anything useful right now, it is not used anywhere. The class is added as part of the task where Attr and its classes are returned to eo-runtime. When all other classes are returned - this class must replace PhRho everywhere.
eo-runtime/src/main/java/org/eolang/AtRho.javaEugene Sukharevr0bari@yandex.ru4691467330DEV4673-7679040113-18
Replace all PhWithRho occurrences with AtWithRho when all other Attr classes are returned to eo-runtime. This class does not do anything useful right now, it is not used anywhere. The class is added as part of the task where Attr and its classes are returned to eo-runtime. When all other classes are returned - this class must replace PhWithRho everywhere.
eo-runtime/src/main/java/org/eolang/AtWithRho.javaRultor.comgpg@rultor.com4692467330DEV4673-7841412b19-25
The {@link AtWithRho#get()} is not thread safe. If multiple threads call get() concurrently when the underlying object lacks RHO, each thread will: 1. Pass the !ret.hasRho() check 2. Create its own copy via ret.copy() 3. Attempt to set RHO on its copy This results in different threads receiving different copies, violating the expectation that get() returns a consistent view of the attribute's value.
eo-runtime/src/main/java/org/eolang/AtWithRho.javaRultor.comgpg@rultor.com4714470230DEV4702-36bb210019-22
Add tests for {@link OnDefault} class. For some reason this class is not covered by tests at all. We need to add unit tests that will cover all possible cases of object name resolution including cases with and without package meta.
eo-parser/src/main/java/org/eolang/parser/OnDefault.java@yegor256yegor256@gmail.com4717470290DEV4702-ca7a17ba214-220
Enable the fibonacci integration test. Currently, the fibonacci integration test is disabled because it fails with the following error: Couldn't find object 'Φ.org.eolang.examples' because there's no class or package 'EOorg.EOeolang.EOexamples'. That said, all the classes and packages are successfully generated by the eo-maven-plugin during the build process.
eo-integration-tests/pom.xml@yegor256yegor256@gmail.com4729471790DEV4717-9bfb9d8d262-264
Move {@link #pinfos(Path)} method to a separate class. Currently, this method violates Single Responsibility Principle of MjTranspile class. After moving, make sure to cover it with unit tests.
eo-maven-plugin/src/main/java/org/eolang/maven/MjTranspile.java@yegor256yegor256@gmail.com4730471790DEV4717-b9941d0d125-134
Check 'package-info.class' existence before looking for an object. Recently, we got an error when 'maven-compiler-plugin' removed 'package-info.class' during compilation and we got quite confusing error message: ``` Couldn't find object 'Φ.org.eolang.examples' because there's no class or package 'EOorg.EOeolang.EOexamples' EOorg.EOeolang.EOexamples ``` Having said that, the 'EOorg.EOeolang.EOexamples' package does exist. The error tells nothing about missing 'package-info.class'. We need to check for the existence of 'package-info.class' before trying to find an object.
eo-runtime/src/main/java/org/eolang/PhPackage.javaYegor Bugayenkoyegor256@gmail.com4718470290DEV4702-c15b070e47-53
EO tests are distributed with the eo-runtime library. Currently, when we add 'eo-runtime' as a dependency, the surefire plugin tries to run its tests as well, which takes significant time. And it's rathter unexpected behavior when we just need to run an EO app. We should either don't include EO tests in the eo-runtime jar, or state it clearly in the documentation that when you add eo-runtime as a dependency, you also get its tests.
eo-integration-tests/src/it/fibonacci/pom.xml@yegor256yegor256@gmail.com4777471890DEV4718-a792fc1024-29
Make {@linkg MjTranspileIT} independent on the previous eo-maven-plugin. The tests in {@link MjTranspileIT} depend on the eo-maven-plugin being installed on the local maven repository instead of using the current one. We should either move these tests to eo-integration-tests, or find a way to use the current eo-maven-plugin build for testing. Otherwise, these tests check the previous version of the plugin.
eo-maven-plugin/src/test/java/org/eolang/maven/MjTranspileIT.java@yegor256yegor256@gmail.com4779477790DEV4777-64b9730f16-21
Continue moving integration tests from eo-maven-plugin to eo-integration-tests module. You can recognize these tests by the -IT suffix. They use Farea to run Maven builds with eo-maven-plugin. After moving all tests, remove the duplicated {@link AppendedPlugin} class from eo-maven-plugin module. Don't forget to remove exclusion from 'simian.yaml' as well.
eo-integration-tests/src/test/java/org/eolang/maven/AppendedPlugin.java@yegor256yegor256@gmail.com4780477730DEV4777-b24e59b018-22
Remove {@link ContainsFiles} duplicate. We have exactly the same class in eo-maven-plugin module. We need to keep only one copy of this class and use it in both eo-maven-plugin and eo-integration-tests modules. Don't forget to remove exclusion from 'simian.yaml' as well.
eo-integration-tests/src/test/java/org/eolang/maven/ContainsFiles.java@yegor256yegor256@gmail.com4743452690DEV4526-efbfb7b425-32
Allow '0.0.0' and 'SNAPSHOT' versions to use cache in FpDefault. For now these versions are treated as non-cacheable, check {@link FpIfReleased}. This behavior causes issues as the following one: <a href="https://github.com/objectionary/eo/issues/4526">Issue 4526</a>. We need to allow these versions to use cache just like other versions. After fixing this, remove @Disabled annotation from {@link FpDefaultTest#usesCacheEvenItSnapshot} and {@link FpDefaultTest#cachesEvenItZeroVersion} tests.
eo-maven-plugin/src/test/java/org/eolang/maven/FpDefaultTest.java@yegor256yegor256@gmail.com4744452690DEV4526-2fba764e56-61
Fix flaky {@link #findsProbesInOyRemote(Path)} test. The test sometimes fails with the following error: MjProbeTest.findsProbesInOyRemote:62 We should find 10 objects in git repository with tag '0.50.0', but 9 found. This might happen because the remote repository structure changes over time. We need to investigate this issue and fix the test to make it stable.
eo-maven-plugin/src/test/java/org/eolang/maven/MjProbeTest.java@yegor256yegor256@gmail.com4756452630DEV4526-0037957c21-23
Add more tests for {@link ChSource} class. Currently, there is only one test that checks the hash computation for a file. We need to add more tests to cover edge cases.
eo-maven-plugin/src/test/java/org/eolang/maven/ChSourceTest.java@yegor256yegor256@gmail.com4817323590DEV3235-2b861aa336-41
Proxy usage in {@link #checksThatWeCanCompileTheProgramWithProxySet(Path)}. Currently, we just check that the build is successful without employing the proxy. We need to enhance this test to ensure that the build process actually goes through the proxy rather than accessing the internet directly. You ought to set up proxy settings using Maven settings.xml with a proxy configured: <a href="https://maven.apache.org/guides/mini/guide-proxies.html">Maven Proxies</a>.
eo-integration-tests/src/test/java/org/eolang/maven/ProxyIT.java@yegor256yegor256@gmail.com4846484090DEV4840-a0c46596386-391
Implement proper cache validation mechanism. Currently, FpDefault relies on file timestamps to decide whether to use the cache or not. This approach is not reliable in many cases. For example, in the transpilation step, the source files are often modified right before transpilation, making the cache always older than the source files.
eo-maven-plugin/src/test/java/org/eolang/maven/FpDefaultTest.javaYegor Bugayenkoyegor256@gmail.com4850484630DEV4846-67023e3119-25
Make Cache thread-safe. The Cache class lacks thread-safety mechanisms. If multiple threads call the apply method concurrently with the same source file, there could be race conditions where both threads determine the cache is stale and attempt to write simultaneously, potentially leading to corrupted files or inconsistent state. Consider adding synchronization or using atomic file operations. See ChCachedTest.java:63-86 for an example of how concurrency is tested in similar caching classes in this codebase.
eo-maven-plugin/src/main/java/org/eolang/maven/Cache.java@yegor256yegor256@gmail.com4851484630DEV4846-24d3519926-29
Replace {@link FpDefault} with {@link Cache}. The FpDefault class currently implements caching logic that is similar to the Cache class. Refactor the codebase to use Cache instead of FpDefault for caching functionality to improve code reuse and maintainability.
eo-maven-plugin/src/main/java/org/eolang/maven/Cache.java@yegor256yegor256@gmail.com4862485160DEV4851-2fc4796029-31
Remove {@link FpDefault} from codebase. The {@link FpDefault} class is used only in tests. We should remove it and all tests that use it.
eo-maven-plugin/src/main/java/org/eolang/maven/FpDefault.java@yegor256yegor256@gmail.com4863485130DEV4851-f3d235c330-36
Repair all the tests in {@link MjLintTest} related to caching. We disabled these tests because of the changes in caching logic, but they should be repaired and enabled again to make sure that caching works as expected. Tests to enable: - {@link MjLintTest#skipsAlreadyLinted} - {@link MjLintTest#savesVerifiedResultsToCache} - {@link MjLintTest#getsAlreadyVerifiedResultsFromCache}
eo-maven-plugin/src/test/java/org/eolang/maven/MjLintTest.java@yegor256yegor256@gmail.com4852484630DEV4846-59b6e8f7100-104
OutOfMemoryError for large files in cache. The sha method reads the entire file into memory using Files.readAllBytes(file) which could cause OutOfMemoryError for large files. Consider using a streaming approach with MessageDigest.update() in a loop to hash the file in chunks, similar to how it's typically done for large file hashing operations.
eo-maven-plugin/src/main/java/org/eolang/maven/Cache.java@yegor256yegor256@gmail.com4853484630DEV4846-00eea77820-23
Add more tests for Cache class. Currently only two basic tests are implemented. More tests should be added to cover edge cases and ensure robustness of the caching mechanism. For example, you can add a test to verify the behavior when the source file is modified.
eo-maven-plugin/src/test/java/org/eolang/maven/CacheTest.java@yegor256yegor256@gmail.com4891488430DEV4884-4327f48e47-52
Replace synchronized statements with ReentrantLock. We are getting the following complaint about {@ling StrictXmir}: StrictXmir.java[244-289]: Use ReentrantLock rather than synchronization (AvoidSynchronizedStatement). It's better to consider this replacement. Don't forget to remove PMD.AvoidSynchronizedStatement from the SuppressWarnings annotation of this class.
eo-parser/src/main/java/org/eolang/parser/StrictXmir.java@yegor256yegor256@gmail.com4899488430DEV4884-50c2998527-29
Use ReentranLock instead of synchronized block in the code. It will be more efficient and will not cause deadlocks. Don't forget to remove the PMD suppression after that.
eo-maven-plugin/src/main/java/org/eolang/maven/Catalogs.java@yegor256yegor256@gmail.com4900488430DEV4884-9430154515-18
Use ReentrantLock instead of synchronized block. This is the suggestion from qulice. Dont' forget to remove the PMD suppression for AvoidSynchronizedStatement after that.
eo-maven-plugin/src/main/java/org/eolang/maven/ConcurrentCache.java@yegor256yegor256@gmail.com4904488430DEV4884-77c26b6c26-29
Use ReentrantLock instead of 'synchronized' in Files. We should use ReentrantLock instead of 'synchronized' to avoid potential deadlocks when multiple AtOnce attributes are used together. Moreover, 'synchronized' keyword is forbidden by qulice.
eo-runtime/src/main/java/EOorg/EOeolang/EOfs/Files.javaYegor Bugayenkoyegor256@gmail.com4905488430DEV4884-45eb808e21-24
Use ReentrantLock instead of 'synchronized' in Heaps. We should use ReentrantLock instead of 'synchronized' to avoid potential deadlocks when multiple AtOnce attributes are used together. Moreover, 'synchronized' keyword is forbidden by qulice.
eo-runtime/src/main/java/EOorg/EOeolang/Heaps.javaYegor Bugayenkoyegor256@gmail.com4906488430DEV4884-97fce65f15-18
Use ReentrantLock instead of 'synchronized' in AtOnce. We should use ReentrantLock instead of 'synchronized' to avoid potential deadlocks when multiple AtOnce attributes are used together. Moreover, 'synchronized' keyword is forbidden by qulice.
eo-runtime/src/main/java/org/eolang/AtOnce.javaYegor Bugayenkoyegor256@gmail.com4907488430DEV4884-73fc285616-19
Replace 'synchronized' with ReentrantLock. We need to replace 'synchronized' with ReentrantLock to avoid potential deadlocks when multiple threads are trying to access the cache simultaneously. Moreover, 'synchronized' keyword is forbidden by qulice.
eo-runtime/src/main/java/org/eolang/PhCached.javaYegor Bugayenkoyegor256@gmail.com4909488430DEV4884-bded9a2115-19
Use ReentrantLock instead of synchronized block in the constructor. This will allow to avoid blocking the whole object while fetching the wrapped one. Moreover, using 'syznchronized' is forbidden by qulice. Don't forget to remove the suppression of PMD.AvoidSynchronizedStatement in the constructor after that.
eo-runtime/src/main/java/org/eolang/PhOnce.javaYegor Bugayenkoyegor256@gmail.com4944453830DEV4538-5f90ad8a239-242
Enable fibonacci integration test when new release of EO is made. The test was disabled because we've moved EO objects from default org.eolang package to root package. That's why many required objects can't be downloaded from objectionary. When fresh release is made, need to uncomment the lines below and enable the test.
eo-integration-tests/pom.xml@yegor256yegor256@gmail.com4945453830DEV4538-4f7f197a33-36
Enable ReadmeSnippetsIT. The test was disabled because we've moved EO objects from default org.eolang package to root package and most of the objects can't be downloaded from objectionary anymore. When new release is made, we need to enable the test.
eo-integration-tests/src/test/java/integration/ReadmeSnippetsIT.java@yegor256yegor256@gmail.com4946453830DEV4538-66cff24a27-39
Enable integration tests. These integration tests were disabled because we've moved EO objects from default `org.eolang` package to root package. These tests stopped working: - {@link MjAssembleIT#assemblesTogether(Path)} - {@link MjRegisterIT#removesOldForeignFile(Path)} - {@link MjRegisterIT#removesUnnecessaryPulledObjects(Path)} - {@link integration.JarIT#runsProgramFromJar(Path)} - {@link integration.JarIT#runsProgramWithPackageFromJar(Path)} - {@link integration.JarIT#runsProgramWithTwoObjects(Path)} - {@link integration.SnippetIT#runsAllSnippets(String, Path)} The most probable reason - most of the tests require downloading objects from objectionary, but since the objects were moved and not released when this todo is written, they are failed to be downloaded. When fresh release is done, need to enable the tests
eo-integration-tests/src/test/java/org/eolang/maven/MjAssembleIT.java@yegor256yegor256@gmail.com4947439435DEV4394-5ca3fe7b26-37
Enable MjLints related tests after `lints` will be adjusted with `Φ` object. For now, lints checks for `Q` instead of `Φ`. After new version of lints released, we should enable these integration tests in MjLintIT, and others: {@link MjLintTest#doesNotFailWithNoErrorsAndWarnings}, {@link MjLintTest#doesNotDetectWarningWithoutCorrespondingFlag}, {@link MjLintTest#skipsAlreadyLinted}, {@link MjLintTest#savesVerifiedResultsToCache}, {@link MjLintTest#getsAlreadyVerifiedResultsFromCache} {@link MjTranspileTest#recompilesIfModified}, {@link MjTranspileTest#recompilesIfExpired}, {@link MjTranspileTest#doesNotRetranspileIfNotModified}, {@link MjTranspileTest#transpilesSimpleEoProgram}, {@link MjTranspileTest#transpilesSeveralEoProgramsInParallel}, {@link MjTranspileTest#transpilesSourcesForDifferentScopesWithoutIntersections}.
eo-integration-tests/src/test/java/org/eolang/maven/MjLintIT.java@yegor256yegor256@gmail.com4948493530DEV4935-676a00f4251-254
Enable `comment-not-capitalized` lint. The lint incorrectly flags comments starting with `@to-do` as not capitalized. We should enable it after the lints repo fixes the issue to ignore @to-do markers. See: https://github.com/objectionary/lints/issues/805
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4949453830DEV4538-cff5e82f258-261
Enable `object-has-data` lint. The lint incorrectly flags all objects with bytes inside because they don't have @base='Φ.org.eolang.bytes'. It was changed in https://github.com/objectionary/eo/issues/4538. Right now we have just Φ.bytes
eo-runtime/pom.xmlYegor Bugayenkoyegor256@gmail.com4950475115DEV4751-97eca98319-22
Move `sqrt` to a separate object with it's tests. It's atom, don't forget change `EOreal$EOsqrt`. For more information check this ticket: https://github.com/objectionary/eo/issues/4751
eo-runtime/src/main/eo/ms/real.eoYegor Bugayenkoyegor256@gmail.com4951475115DEV4751-14ad8ad226-29
Move `ln` to a separate object with it's tests. It's atom, don't forget change `EOreal$EOln`. For more information check this ticket: https://github.com/objectionary/eo/issues/4751
eo-runtime/src/main/eo/ms/real.eoYegor Bugayenkoyegor256@gmail.com4952475115DEV4751-147134e633-36
Move `acos` to a separate object with it's tests. It's atom, don't forget change `EOreal$EOacos`. For more information check this ticket: https://github.com/objectionary/eo/issues/4751
eo-runtime/src/main/eo/ms/real.eoYegor Bugayenkoyegor256@gmail.com4953475115DEV4751-d70283d841-44
Move `asin` to a separate object with it's tests. It's atom, don't forget change `EOreal$EOasin`. For more information check this ticket: https://github.com/objectionary/eo/issues/4751
eo-runtime/src/main/eo/ms/real.eoYegor Bugayenkoyegor256@gmail.com4954453830DEV4538-f772932625-30
Enable the test {@link DataizedTest#doesNotLogGoToTokenJump}. The test was disabled because we've moved EO objects from default package 'org.eolang' to Q, but java classes are placed in 'org.eolang' java package. That's why the method {@link PhDefault#forma()} and {@link PhSafe#forma()} started to work incorrectly and show 'org.eolang'. Need to fix these methods, make sure they work as expected and enable the test.
eo-runtime/src/test/java/org/eolang/DataizedTest.javaYegor Bugayenkoyegor256@gmail.com4955453830DEV4538-2dd5751c31-34
Enable the test {@link DataizedTest#logsAllLocationsWithPhSafe()}. The test was disabled because we've moved EO objects from default package 'org.eolang' to Q. This somehow affected {@link PhSafe} and {@link PhDefault} classes. Need to fix it and enable the test
eo-runtime/src/test/java/org/eolang/DataizedTest.javaYegor Bugayenkoyegor256@gmail.com4983494090DEV4940-1e013c5029-32
Enable MjLintTests when WPA cache is ready. We need to enable the following test when we implement WPA cache. {@link MjLintTest#savesForWholeProgramAnalysisResultsToCache} For now, WPA results are not saved to cache.
eo-maven-plugin/src/test/java/org/eolang/maven/MjLintTest.java@yegor256yegor256@gmail.com