Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

VIATRA/DeveloperMeetingMinutes/Meeting20180125

Topics

  • Current status: Bugzilla Gerrit AERI
  • VIATRA 2.0 status
    • UI test failures in recent builds - still unsolved
    • Guava reduction - done
    • Merging patternlanguage and patternlanguage.emf - almost done
  • 1.7.1 and 2.0.0 M2 next week
  • Performance issue in EVM when number of activations change greatly https://bugs.eclipse.org/bugs/show_bug.cgi?id=530057
  • Oszkár + Dani: Question about integration of EMF + VQL with VIATRA-Solver

Minutes

  • UI tests still failing
  • Guava reduction done: runtime API has no visible Guava usage
  • Merging base and emf pattern language
    • Change will be submitted, part of M2
  • 1.7.1 and 2.0.0 M2 will be released as planned
  • Performance issues in EVM:
    • In case of Executor/ScheduledExecution, it depends on ConflictSet implementation
    • In Rete, a similar issue was circumvented by creating a new set when the size becomes small
  • VIATRA-Solver configuration language VQL integration
    • Suggestions:
      • Do not use file paths in configuration DSL
      • Use Xtext index for accessing EPackage and Patterns with FQNs
      • Headless application should setup Xtext resource set before parsing config
      • Only restricted use and scope for command line option (for beginners): e.g. single metamodel, all queries in one file, etc.

VIATRA 2.0 plans

  • VQL parsing error handling issues
    • Mostly trivial fixes
  • VQL standalone parsing library support
    • Some changes might be necessary here
  • Base index internal refactor
    • Concrete issues as motivated by measurements
  • Query specification builder API
    • Multiple requests
    • Could support non-EMF scopes
    • The effort requirement is not too high
  • Streams (even ITuple streams) in Base and query APIs (requires public API changes)
    • Required to implement lazy Local Search evaluation, e.g. not to calculate matches until previous matches were processed
    • Not too complex to implement
  • More expensive or less important ideas
    • Merging PQueryHeader and IInputKey (and related calls)
      • Allows uniform handling of base index access and pattern composition
    • Custom relations as simple tables
    • Inline neg and aggregator access for type constraints and path expressions)
      • Removes need for a lot of trivial pattern calls
      • Can be implemented as syntactic sugar in grammar
    • avg aggregator
      • Very easy to implement
      • Low priority
    • Gradle plug-in for generating code from VQL
      • Unknown amount of effort necessary

Back to the top