Skip to main content
Topics
- Current status: Bugzilla Gerrit AERI
- TODOs from last meeting
- TODO: Issue management
- TODO Zoltan, Gabor: Check Eclipse Collections 7.x
- TODO: evaluate Xtext scoping update on multiple user machines
- TODO Balázs: evaluate and test code generation strategies
- Ongoing tasks
- Surrogate objects in base index
- Eclipse Collections integration
- Xtext scoping experiments for performance
- Backward compatibility issue with 1.6 related to dangling edges
- 1.7 progress
- New CPS benchmark run: https://build.incquerylabs.com/jenkins/job/viatra-cps-benchmark/168/artifact/benchmark/
- Rete fixes included (Eclipse Collections, Tuple optimization)
- Generic local search also included
Minutes
- Eclipse Collections integration merged, dependency added to update site
- Release train uses 8.2.0 release site
- Photon M3 will probably include EC9.0.0
- Will be benchmarked on various projects
- Alternative scoping not yet tested as far as we know
- TODO Balazs: please test when you have time
- Code generation strategies
- TODO Balázs: please test when you have time
- Dangling edges backward compatibility issue
- Behaviour temporary changed during 1.5.x, compared to before 1.5.1 and after 1.6.0
- Still no internal tests for this functionality (both base index and query engine?)
- István: keep current default for VIATRA 1.x, reconsider scope semantics for 2.0
- 1.7 progress
- M2 with Xtext 3.0.0 upper bound contributed to Photon M2 (includes Xtext 2.13)
- CPS benchmark
- Results around as expected
- Generic LS transient (peak) memory similar to Rete, probably due to tuple objects used on the API (very-very short lived objects)
- Gaben: in the FUTURE, we could write generators for typical Tuple classes
- Longer term visions for query language and metamodel access
- Several discussions about possible approaches (Java vs. Ecore type systems)
- Current infrastructure needs to map from EMF types to Java classes
- We could either move from EMF to Java classes, ditch Xbase as expression language or build out a fast cache for the current system
- Moving to Java classes makes generic API usage problematic
Back to the top