VIATRA/DeveloperMeetingMinutes/Meeting20170921

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
    • https://dev.eclipse.org/mhonarc/lists/viatra-dev/msg00743.html
• Backward compatibility issue with 1.6 related to dangling edges
  • • https://dev.eclipse.org/mhonarc/lists/viatra-dev/msg00741.html
• 1.7 progress
  • 1.7.0 M2 out
  • Xtext 2.13
• 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