Tags: abstools/abstools
Tags
Release v1.11.1 # Added - ABS embedded SPARQL queries over lifted program state can now take parameters, similar to the existing SQLite queries. # Fixed - Fixed a race condition between object initialization and method call scheduling in the Java backend.
Release version v1.11.0
# Added
- The Java backend now implements semantic lifting, i.e., representing
model structure and runtime state as RDF.
- Running a model with the argument `--printRDF` will print the RDF
graph after the model has finished.
- Running a model with the argument `--sparqlQuery` followed by a
SPARQL query will run and print the result of the query after the
model has finished.
- The Model API offers an additional URL `/sparql` that implements a
SPARQL endpoint as specified in Section 2.1 of
<https://www.w3.org/TR/sparql11-protocol/>.
- Running the abs compiler with `--domain-ontology ontology.ttl`
adds the content of `ontology.ttl` to the lifted program state.
- Adding an annotation `[DomainClass: e]` to a class definition,
with `e` an expression over the object state returning a string,
will add a triple `o rdf:type c` to all lifted objects of class
`C` (where `c` is the result of evaluating `e` at runtime).
- In the Java backend, it is now possible to define functions that
query the lifted program state. For example, the following function
find objects that implement an interface `Test.I`:
```
def List<I> find_objects() = builtin(sparql,
`SELECT ?o WHERE {
?o a/abs:implements/rdfs:label "Test.I" .
}`)
```
See the manual for more details. Note that this querying facility
is provisional and its semantics might change.
- The expressions `x implements I` and `x as I` are now implemented by
the Java backend.
- In the Java backend, relative filenames (such as sqlite databases)
are now resolved against the directory given by the `--datadir`
parameter or `abs.datadir` property. If no directory is specified,
such filenames are resolved against the current directory as
before.
# Changed
- The standard library section of the reference manual now contains
short usage examples for each function.
- The Java backend now uses virtual threads instead of OS-native
threads to implement ABS processes. This change lets the Java
backend run models of similar size as the Erlang backend in terms of
number of processes.
- The toolchain now requires Java 25.
- The source for the language manual and the abs-models.org website
have been merged, and ported to the Sphinx website generator and rST
(reStructured Text) format.
# Fixed
- We now use upstream ChocoSolver 5 instead of a vendored jar archive
of ChocoSolver 2. ChocoSolver 2.0 used deprecated private APIs that
were removed in Java 25, and neither source nor documentation was
available.
Release version 1.10.2 # Added - A new function `range(a, b)` in the standard library returns a list of integers ranging from a to b (inclusive). - The expressions `x implements I` and `x as I` are now implemented by the Java backend. - In the Java backend, relative filenames such as sqlite databases are now resolved against the directory given by the `--datadir` parameter or `abs.datadir` property. If no directory is specified, such filenames are resolved against the current directory as before.
Release version 1.10.1 (#361) * Added - Added documentation for compiling and running ABS models inside a Java project using the gradle build tool. * Changed - Refactor the Java backend to use Java-native datatypes directly instead of wrapping them inside subclasses of `ABSDataType`: - Instead of `ABSString`, use `java.lang.String` - Instead of `ABSBool`, use `java.lang.Boolean` - Instead of `ABSFloat`, use `java.lang.Double` - Instead of `ABSRational`, use `org.apfloat.Aprational` - Instead of `ABSInteger`, use `org.apfloat.Apint` - Implement ABS user-defined datatypes as Java `record`s - Refactor the Java backend to use Java 21 pattern matching and record patterns to implement the ABS `switch` statement and `case` expression instead of creating temporary matcher and binding objects. This should significantly reduce memory use when processing large datastructures. * Fixed Various bug fixes and minor refactorings.
Release version 1.10.0
* Added
- Added a new expression `destiny` that evaluates the future of the currently-running task. Since a synchronous method call does not get a new future but has a different return type, `destiny` is typed with the new type `Destiny`, a supertype of all futures.
- Added a new process attribute `destinyOf`, useful in user-defined schedulers, that returns the future of a given process.
- In the Erlang and Java backends, it is now possible to define functions that read from a provided SQLite database: `def List<Int> f(Int x) = builtin(sqlite3, "db.sqlite3", "SELECT i FROM t where i > ?", x);` will return a list of numbers greater than `x` in table `t` of database file `db.sqlite3`. See the manual for more details.
- The Java backend now supports Timed ABS, as documented in Chapter 13 of the manual.
- The Java backend now supports deployment and resource modeling, as documented in Chapter 15 of the manual.
- The Java backend now supports the Model API, as documented in Chapter 12 of the manual.
- The scripts `absc` and `absc.bat` to invoke the compiler are now located in `frontend/bin/`. For backwards compatibility, the old script locations still work.
- The java backend can now optionally generate a jar file that can run the compiled model stand-alone:
- Use the `-o` option to create a jar file, e.g., `absc -j model.abs -o model.jar` (by default, no jar file is generated).
- To run the generated jar file, use `java -jar model.jar`.
- Regardless of the presence of this option, the Java backend will always generate Java source and class files in the `gen/` subdirectory (or the directory specified via `-d`).
* Changed
- The toolchain now requires Java 21, Erlang >= 26 and a C compiler.
- The Java backend now requires the full JDK (Java Development Kit) to be installed when compiling ABS models; previously it was possible to run the tool chain after installing only the JRE (Java Runtime Environment). (Note that the JDK was always required to compile the toolchain itself.)
- The Java backend now compiles generated files with the same version of the Java compiler that the backend itself was compiled with; previously, the Java backend was hardcoded to use Java 1.5 as compilation target.
- The syntax for command-line options was changed for models generated via the Java backend: instead of, e.g., `--randomseed=1234` use `--randomseed 1234`.
- Minor incompatible change: the built-in function `toString` now encloses String arguments for user-defined datatypes in quotes. I.e., for a datatype `data Person = Person(String, Int);`, the expression `toString(Person("Joe", 20))` produces `Person("Joe",20)` instead of `Person(Joe,20)`. For string values, `toString` produces the string without quotes as before.
* Fixed
- Removed the one-minute timeout for the Model API (calls to the Model API used to abort with a 5xx error code after one minute, no matter whether the associated task was still running and would have completed successfully).
Release version 1.9.3 - The toolchain now requires Java 11 or later. - The long command-line parameter names for recording and replaying traces have been changed from `--dump-trace` and `--replay-trace` to `--record` and `--replay`. The short parameters stay the same (`-t` and `-r`, respectively). - Performance improvement in the Erlang backend: a cog with multiple processes awaiting on Boolean conditions now evaluates all guards in-process instead of delegating to the waiting processes. This results in better performance -- observed an improvement factor of 3-9 and utilization of a single core (as opposed to running on all cores of a multi-core machine) in microbenchmarks involving a single cog.
Release version 1.9.2 * Added - A first version of location type checking has been added. This feature is currently not enabled by default. Use the parameter `--loctypecheck` to enable location type checking. Location types express whether a given object resides on the same cog as the current object; see Section 3.6 in the manual for initial documentation. * Fixed - A deadlock in the erlang backend has been fixed. #276
1.9.1 - 2020-11-27
* Added
- The `foreach` loop now supports an optional second variable of type `Int` that is bound to the index of the current element, starting at zero. The syntax is `foreach (elem, index in list) { ... }`.
- The second argument to the `duration` statement and `await duration` guard is now optional; `duration(x)` has the same behavior as `duration(x, x)`.
- The new function `ms_since_model_start` returns an integer containing the elapsed time in milliseonds since the model was started.
- The Model API in the erlang backend can now export its endpoints with a link prefix via the `--url-prefix` command-line option.
* Changed
- Function calls in the erlang backend are significantly faster via removal of the check for pending garbage collection at the beginning of each function body. (Note that garbage collection, i.e., removing unreferenced futures and objects, happens rarely, so the increased waiting time when entering gc caused by this change is not paid often.)
- The import/export combination `import A from OtherModule; export A;` now issues a compile-time warning instead of an error. This keeps older models running while announcing the upcoming change. (The same construct is an error in the xtext branch already.)
- In the Erlang backend, wall-clock time for running a model is now reported in milliseconds instead of microseconds. (To see the elapsed time, start the model with parameter `-v`.)
* Fixed
- Fixed a potential hang in the erlang backend.
* Added - The `case` pattern matching expresssion now uses bars (`|`) to separate case branches. The older syntax (`;` to terminate each branch) is still supported by the parser and will not lead to compile-time warnings. * Changed - Incompatible change: deltas now share a namespace with modules. Defining a delta with the same name as a module results in a compile-time error. - Incompatible change: the plain export clause `export Name;` will only export `Name` if `Name` is defined in the current module; use `export Name from OtherModule;` to re-export `Name` imported from `OtherModule`. This mirrors the behavior of `export *;` vs. `export * from OtherModule;`. - Future incompatible change: the pattern matching statement now uses the keyword `switch` instead of `case`. The pattern matching expression uses `case` as before. Using the old syntax emits a compile-time warning. - Future incompatible change: The conditional expression now uses the keyword `when` instead of `if`. The conditional statement uses `if` as before. Using the old syntax emits a compile-time warning. * Fixed - Multiple `uses` clauses in a delta now cause a compilation failure. The parser used to accept deltas with more than one `uses` clause, but all clauses except the first were silently ignored. - It is now possible to use qualified names in `adds` module modifier clauses in deltas. - The error message when using a simple name in a modifier clause in a delta without a `uses` clause has been clarified.
PreviousNext