Similar to our CMake integration, it would be nice if we could also have something similar for Vitis HLS.

This would work with a simple workflow: after we perform our HLS-related code transformations and directive insertion, we could synthesize the code with Vitis HLS, and parse the synthesis report into a JS-friendly format (i.e., JSON).

This would allow us to automatically estimate the performance of our transformed code using HLS, enabling processes like full Design Space Exploration in the near future.

Possible API usage

// after code transformations
const vitis = new VitisHLS();

vitis.addSource("foo.c");
vitis.setTopFunction("matrix_multiply");
vitis.setPlatform("xcvu5p-flva2104-1-e");
vitis.setClock(10);

var success = vitis.synthesize();
if (success) {
    var report = vitis.parseReport();
    println("Design latency: " + report["latency"]);
}

How to implement it

I think there is some intersectionality with the CMake extension, particularly when it comes to managing input files with the CMakerSources class. One idea could be to extract common functionality to a parent abstract class, and then to have extended classes for both CMake and Vitis HLS.

The integration with Vitis HLS itself is easy, as Vitis HLS works well as a command-line application and I already have the required scripts/commands to implement the entire flow, from creating a Vitis project to generating the synthesis report.

Adapt current documentation framework that currently supports LARA files to also support JS files

I noticed a consistent behaviour where folding works just fine in .lara files, except for the main lara file. Lets say my current lara file is Main.lara. As is, folds do not work. If I change my main lara to another file, folds in Main.lara work again! Therefore, I suspect the CurlyFoldParser is working as intended, but some settings are applied on the main Lara tab (treated especially) that are not applied on the other tabs? Or vice-versa?

Currently we are using a custom HTML generator that receives as input the populated documentation model. However, we could output instead to some markdown and use a website generator. Options include Jekyll (used by GitHub pages), ReadTheDocs, DocPress, etc .

          That is true. The move was done since Clava was the only Weaver that actually supported this API, I assumed it was the only one where it would be used.

As for adding .code as an attribute of the base joinpoint type (LaraJoinPoint), I agree. I had planned for us to have a discussion about this in the near future.

Originally posted by @lm-sousa in #41 (comment)

When calling a LARA aspect by command-line with input arguments (e.g., -av {arg1:10}) and the main aspect does not have inputs, the following exception occurs:

Exception in thread "main" java.lang.RuntimeException:
During LARA Interpreter execution
caused by RuntimeException:
when evaluating javascript
caused by ScriptException: TypeError: Cannot get property "length" of null in at line number 23
caused by ECMAException: TypeError: Cannot get property "length" of null
at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)

Documentation model does not store information about super classes of classes.

• For JS code that information is in the AST;
• For LARA code that information would have to be extracted (but not might be needed if .lara is transformed into .js in the future);
• There should be a link between the super and the destination class, if it exists in the documentation model. This could be a post-processing step;

All these code snippets show the same information replicated across the codebase.
These should be consolidated into a single source of truth.

https://github.com/specs-feup/lara-framework/blob/af1ab2e7b36777f19ae96bc1ef0bdf546e37b3d9/WeaverGenerator/src/org/lara/interpreter/weaver/generator/generator/java/helpers/SuperAbstractJoinPointGenerator.java

There are some parts of HTML generation that should be improved:

• Folders should have descriptive names, instead of numbers, to reduce changes when generating the documentation;

• Should generate static HTML pages, instead of the current version that dynamically loads parts of the webpage using JS;

To obtain comments from LARA files, currently the files are being parsed using the legacy method, which converts LARA to AspectIR. Instead, use JavaCC21 parser and tree.

Will need to adapt the way comments are extracted and populated.

          Set<string> | undefined

Originally posted by @joaobispo in #41 (comment)

The function laraImport() is used to load .js files. Usually all variables declared in the loaded file become available in the scope they are loaded, but the only guarantee of the laraImport() function is that a variable with the same simple name of the import will become available in the global scope (e.g. import weaver.Query will make the name Query available globally).

Of course, for files to be compatible with being loaded with laraImport(), must be written in such a way so that they create a variable with the same name as the file.

.mjs files have different scoping rules, so when laraImport() loads the files, in some cases (e.g. JS classes) the declared variable does not become visible in the global scope. This breaks compatibility with code that uses laraImport().

          Noted. Also, there are 297 instances of `public static final` variables in our code-base that need to be addressed.

Originally posted by @lm-sousa in #41 (comment)

Currently arguments are passed from the weaver to the scripts through a global variable that is always present, laraArgs.

This should be re-implemented as an API that scripts that want to use must import, even if it continues to have global (read-only) state. This implies:

• New API
• Tests for laraArgs

By default, Query.search() performs a preorder traversal. However, sometimes postorder traversal is necessary.

Add support for specifying if we want a preorder or postorder traversal. Current proposal is to add an additional flag to Query.search() of an enum {preorder, postorder}, where preorder is the default value.

There is already a kind of support for default options, with the file local_options.xml, but it is limited to specific options defined for that file.

Implement a more generic mechanism which can accept common weaver configuration files.

          Should be abstract?

Originally posted by @joaobispo in #41 (comment)

          Add jest test for this?

Originally posted by @joaobispo in #41 (comment)

When in the new Node.js environment, if we access a property of a joinpoint the return values may be mangled.

Let's take the rank property of Clava's CxxLoop joinpoint. The documentation says this property returns an array of numbers (number[]). This is true, to a point. The actual getter returns an Object type. A data type of GraalVM to represent javascript data-structures. This happens because the old implementation calls JsEngine.toNativeArray before returning to the javascript environment. In the new JsEngine implementation for the Node.js this toNativeArray method just returns the original object without modifications. However, in the end, due to the function type of the original getter, the array always gets cast to the Object datatype.

My suggestion in this case is to move the datatype conversion logic to the javascript environment just as we have been doing with all the other Java objects. I imagine this will require modifying the WeaverGenerator and/or the LanguageSpecification as even the Abstract joinpoint classes have this Object datatype as the getter return type.

Cytoscape is looking into publishing its own typings for the library.
Once it does, we can update our own APIs.

Ref: cytoscape/cytoscape.js#3166

          verify that the predicate can receive any in future PRs

Originally posted by @joaobispo in #41 (comment)

          The idea of passing the function instead of a list was to allow, in the future, for the function to return an iterable, instead of forcing the creating of a list with all jps before the filtering.

Add a comment with this information, that for streaming to be implemented, we will need to change the input list to be for instance, an iterable/generator.

Right now, we should be very close for search() to work in a stream-like way, on the Java-side the base methods already return Streams.

Originally posted by @joaobispo in #63 (comment)

The use of LaraCore.LaraGetter is interfering with the new JS Joinpoint wrappers

When updating the Java resources in Lara Classic and the modules folder is updated, the "java" mock npm module is deleted and not recognized during execution. The second time the framework is executed, the "java" module is recognized and the application runs as intended.