Hi all, I have recently been working on org.eclipse.epsilon.eol.execute.operations.declarative and have made a number of additions and improvements. These are as follows: - Parallel variants of all first-order operations except for aggregate and closure under the org.eclipse.epsilon.eol.execute.operations.declarative.concurrent package. These can be invoked by adding “parallel” prefix to the operation – e.g. select becomes parallelSelect. These operations can be used in any Epsilon language on-the-fly seamlessly without setting up parallel execution infrastructure (i.e. you don’t need to use a special IEolModule or IEolContext beforehand – the setup is done in the operations themselves).
- Added EUnit tests for all first-order operations under org.eclipse.epsilon.eol.engine.test.acceptance.firstOrder. This includes tests for both sequential and parallel variants, as well as equivalence tests, scope tests (i.e. visibility of global variables) and exception handling.
- select (and parallelSelect) now takes an additional parameter. Before it was “boolean returnOnMatch” (allowing for selectOne). Now it also takes “boolean isSelect”, allowing for reject.
- Added rejectOne (and parallelRejectOne) in same codebase as select (and parallelSelect).
- Refactored one operation to short-circuit when not enough or too many matches are found. Previously this just called select and checked the size == 1, which was inefficient.
- Added none operation (as well as parallelNone). As with one, this short-circuits. The codebase for one and none is generalised as nMatch where n = 1 for one and n = 0 for none.
- forAll (and parallelForAll) delegate to nMatch where n is the size of the source collection. This also fixes the bug with variables leaking as “scope.leaveLocal(_expression_)” was not previously called when short-circuiting.
- sortBy (and parallelSortBy) now use arrays for intermediate results, saving memory and making it possible to perform sorting in parallel using java.util.Arrays.parallelSort. Note that Arrays.parallelSort will sort sequentially if the length of the array is less than 8192. This conveniently allows the codebase to be shared between sequential and parallel, by introducing “CollectBasedOperation” in the same way as “SelectBasedOperation” and using parallelCollect as the delegate for parallelSortBy.
- Updated Epsilon book with newly added operations and a note on the existence of parallel variants, as well as restrictions on using them.
Currently the restrictions on using the parallel variants of first-order operations are as follows: - No nested parallel operations – e.g. “col.parallelSelect(d | d.prop.exists(p | <expr>))” is valid but “col.parallelSelect(d | d.prop.parallelExists(p | <expr>))” is not.
- No side-effects are permitted. This means no invocations of operations which modify global variables or extended properties.
- Cannot be used with parallel EVL (or any other parallel execution engine, for now).
I hope that this will be useful. Please let me know if you have any questions or comments. Thanks, Sina Madani |
