Incremental Program Analysis Framework

Related tags

Learning Resources dsl program-analysis mps domain-specific-language analysis-framework incremental-computation language-workbench
Overview

IncA

Overview

IncA is a program analysis framework. It comes with a DSL for the definition of program analyses and the runtime system evaluates program analyses incrementally to achieve the performance that is needed for real-time feedback in IDEs. When code gets changed, the IncA runtime system incrementally updates analysis results instead of the repeated recomputation from scratch. IncA program analysis code is translated into graph patterns, and we reuse existing incremental graph pattern matching solutions to evaluate the analysis code on the AST of the analyzed program.

Getting Started

IncA is tightly integrated into the JetBrains MPS language workbench (https://www.jetbrains.com/mps/). The primary goal of this integration is to make analysis development and maintenance an integral part of the language development process. Getting started with IncA is easy, it only requires Java 11 and MPS 2019.3.x. Note that there are maintenance branches for earlier MPS versions (e.g. 2018.3, 2019.1, 2019.2), as well. Keep in mind that MPS versions <= 2019.1.x used Java 8 instead of Java 11.

The project is equipped with a Gradle build, and setting up the project requires the cloning of this project and running ./gradlew in the root directory from a command line. The default gradle task takes care of downloading all dependencies and building IncA itself. Note that the build downloads MPS itself because it is required for building IncA, though, the downloaded MPS application is independent from any of your existing MPS installations. Once the project is built, you can start using IncA by opening the code directory (under the root directory) in MPS. Once you have opened the project in MPS, you need to set up a path variable inca.home in MPS Preferences -> Appearance & Behavior -> Path Variables. The path variable must point to the root folder of the git repository clone.

Pro tip: you can customize the contents of the MPS project libraries for IncA by creating a file libraries.overrides.properties in the root directory. The key-value pairs in this file will override the contents of the libraries.properties while generating the libraries.xml file for the project during the Gradle build.

Videos

The following videos provide a good starting point to explore IncA.

Better living through incrementality: Immediate static analysis feedback without loss of precision, Tamás Szabó, Sebastian Erdweg, SPLASH-I, 2018

vid1

Incrementalizing Lattice-Based Program Analyses in Datalog, Tamás Szabó, OOPSLA, 2018 vid2

Publications

IncA is a research project, and its various features have been documented in the following publications:

  • Incrementalizing inter-procedural program analyses with recursive aggregation in Datalog, Tamás Szabó, Gábor Bergmann, and Sebastian Erdweg. In Workshop on Incremental Computing (IC), 2019. [pdf]

  • Incrementalizing Lattice-Based Program Analyses in Datalog, Tamás Szabó, Gábor Bergmann, Sebastian Erdweg, and Markus Völter. In Proceedings of Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), 2018. [pdf]

  • Incremental Overload Resolution in Object-Oriented Programming Languages, Tamás Szabó, Edlira Kuci, Matthijs Bijman, Mira Mezini, and Sebastian Erdweg. In Proceedings of International Workshop on Formal Techniques for Java-like Programs (FTfJP), 2018. [pdf]

  • IncAL: A DSL for Incremental Program Analysis with Lattices, Tamás Szabó, Sebastian Erdweg, and Markus Völter. In Workshop on Incremental Computing (IC), 2017. [pdf]

  • IncA: A DSL for the Definition of Incremental Program Analyses, Tamás Szabó, Sebastian Erdweg, and Markus Völter. In Proceedings of International Conference on Automated Software Engineering (ASE), 2016. [pdf]

Examples

There are several example analyses in the project's tests folder (inside MPS). These examples range from simple analysis, like querying various properties of a small DSL that describes families and relationships, to complex program analyses, like strong update points-to analysis or static analyses of string values.

Contact

Feel free to get in touch if you would like to discuss about, contribute to, or simply use IncA. You can find all relevant contact information on szabta89.github.io.

Comments
  • Editor errors are ignored

    Editor errors are ignored

    When there are errors in a pattern function module, IncA should refuse to compile, but the current behavior is that it will happily compile and run the analysis.

    opened by sander2 9
  • Universal quantification

    Universal quantification

    It happens quite often that you need to assert that a function is defined for all items in some list (or set of tuples). There are ways to implement this in IncA, but they each have their drawbacks.

    1. Through recursion
    def containerOk(c: Container) {
  e := c.elems
  assert undef e.prev
  assert def checkElemListRecursively(e)
} alt {
  assert undef c.elems
}
def checkElemListRecursively(e: Elem) {
  // omitted: assert that e is valid

  switch {
    assert undef e.next
  } alt {
    assert def checkElemListRecursively(e.next)
  }
}

    This is not very nice to write and the recursive nature likely has a negative impact on the performance. Also, it only works on lists and not on a set a values returned by a function.

    1. Through negation
    def containerOk(c: Container) {
  assert undef containerElemNok(c)
}
def containerElemNok(c: Container) {
  e := c.elems
  // omitted: assert that e is invalid
}

    This has the downside that it uses undef, which in some situations can lead to negation in recursion. On the upside, there is less boilerplate required than the other solutions.

    1. Through lattice aggregation
    def containerOk(c: Container) {
  assert containerElemOk(c) == BoolLattice.True
}
def containerElemOk(c: Container) : BoolLattice/intersection {
  e := c.elems
  
  switch {
    assert def elemOk(e)
    return BoolLattice.True 
  } alt {
    assert undef elemOk(e)
    return BoolLattice.False
  }
} alt {
  assert undef c.elems
  return BoolLatice.True
}
def elemOk(e: Elem) {
    // omitted: assert that e is valid
}

    Like the previous solution, this has the downside that an undef is required (in the second alternative of the switch). Also, it's a bit verbose. However, its performance is likely better than the recursive solution.

    Ideal solution

    Some kind of support for universal quantification. Something like the example below would be ideal.

    def containerOk(c: Container) {
  // universal quantification on a list:
  foreach e in c.elems {
    // omitted: assert that e is valid
  }
  // it would be even better if it would also work on the result of a function call:
  foreach e in getAllElems(c) {
    // omitted: assert that e is valid
  }
}

    Implementation

    It's probably fairly easy to transform the suggested syntax into code as shown in case 2 or 3. That would, however, introduce assert undefs. Could these be avoided somehow?

    opened by sander2 3
  • allow cyclic imports

    allow cyclic imports

    Removed the restriction that disallowed cyclic imports.

    you will need to examine the scope implementations to see if they wont end up in an infinite loop in the presence of cycles because the scopes traverse the imports transitively

    This appears not to be an issue. For checking scopes, the getImportedModules method in IIncaModule_Behavior is called, in which infinite loops are prevented by keeping track of the visited modules. I also verified this by checking that code with cyclic imports compiles without problems.

    Edit: since you introduced the acyclicity constraint for “nice code design purposes”, perhaps you would like a warning or an info on imports that create a cycle?

    opened by sander2 3
  • switch causing error

    switch causing error

    This code causes an error type y8 is not a subtype of (node<>, node<FunctionArg>), located on the first alternative of getUniqueInputLifetimes1:

    join type LifetimeDeclarator = Lifetime | PointerType
                                                     
private def getUniqueInputLifetimes1(f : Function) : (LifetimeDeclarator, FunctionArg) = { 
  arg := f.args 
  ty := arg.ty 
  q := typeGetUsedPointerTypes(ty) 
  switch { 
    assert undef q.lifetime 
    return (q, arg) 
  } alt { 
    lifetime := q.lifetime 
    decl := resolveLifetime(lifetime, lifetime) 
    return (decl, arg) 
  } 
}

    Even though the manually desugared version works just fine:

    private def getUniqueInputLifetimes2(f : Function) : (LifetimeDeclarator, FunctionArg) = { 
  arg := f.args 
  ty := arg.ty 
  q := typeGetUsedPointerTypes(ty) 
  assert undef q.lifetime 
  return (q, arg) 
} alt { 
  arg := f.args 
  ty := arg.ty 
  q := typeGetUsedPointerTypes(ty) 
  lifetime := q.lifetime 
  decl := resolveLifetime(lifetime, lifetime) 
  return (decl, arg) 
}

    (code pushed to my switch-error branch)

    opened by sander2 3
  • unexpected behavior in `assert undef a.b.c`

    unexpected behavior in `assert undef a.b.c`

    These two snippets behave differently when a.b is defined, but a.b.c is not:

    assert undef a.b.c

    and

    tmp := a.b
assert undef tmp.c

    Ideally, assert undef a.b.c should be equivalent to:

    switch{
    assert undef a.b
} alt {
    tmp := a.b
    assert undef tmp.c
}

    If that's not possible, then only using the second part of the switch would be acceptable. If that's not possible either, then a compiler error should be thrown when this construct is used.

    opened by sander2 3
  • incorrect analysis result

    incorrect analysis result

    I think I found another bug. I have two functions, f1 and f2. I expect these to behave identically, but they do not. While f2 works as expected, f1 does not yield any tuples, even though g1 returns no tuples where the first argument is a Lifetime.

    join type LifetimeRelated = Lifetime | LifetimeDefinition                                                                                                                     
                                                                                                                                                                              
def g1(from : LifetimeRelated, l : Lifetime) : Void = { 
  assert from instanceOf LifetimeDefinition 
  lifetimeNode := from.lifetime 
  assert lifetimeNode.name == l.name 
}
                                                                                                                                                                              
private def f1(l : Lifetime) : Void = { 
  assert undef g1(l, l) 
}                                                                                                           
private def f2(l : Lifetime) : Void = { 
  assert def f2_helper(l, l) 
}                                                                                                      
private def f2_helper(l1 : Lifetime, l2 : Lifetime) : Void = { 
  assert undef g1(l1, l2) 
}                                                                                  
                                                                                                                                                                              
// unused fucntion, added to see how it compiles                                                                                                                              
private def h1(s : LifetimeDefinition) : Void = { 
  bla := s.lifetime 
}

    The code I'm analyzing is struct Y1 < 'a > { } and the result is (notice the difference between f1 and f2):

    Typing.g1 (1)
    "from"=LifetimeDefinition, "l"='a
Typing.f1 (0)
Typing.f2 (1)
    "l"='a
Typing.f2_helper (1)
    "l1"='a, "l2"='a

    Even though g1 returns the correct tuples, I found its transformed code to be suspicious: image

    Note that lifetime is looked up in BaseConcept, whereas in h1 it's (correctly) looked up in LifetimeDefinition. I'm not sure how that would cause f1 to misbehave, but I thought I'd mention it anyway.

    I pushed the example to my repo under the same-var-bug branch.

    opened by sander2 3
  • [low priority feature request] IncA Explorer node labels

    [low priority feature request] IncA Explorer node labels

    In my AST I often have a lot of nodes of type Path. These paths do not implement INamedConcept, so in the IncA explorer, these simply show up as Path. It would be great if there were some way to override the name displayed in the explorer, such that I don't have to double click on every single Path to find the one I'm looking for.

    opened by sander2 1
  • slow computation network construction

    slow computation network construction

    Building the computation network takes a long time for complicated analyses (this should be reported to Viatra at some point); in my case, it takes about 10-15s. This initialization seems to be separately for each model that is analyzed. As a result, my test suite, which analyzed three different models, spent a lot of time recomputing the computation network. For now, I have merged all my three (test program) models to greatly speedup testing time.

    opened by sander2 1
  • IDE cpu usage

    IDE cpu usage

    I pushed some code to slow-ide2, which, when the test is run, generates about 10000 lines worth of error messages. When the test is done and when the first result is single-clicked (i.e. test_core), CPU usage goes to 100% for about a minute (even though the editor remains responsive). I believe this is caused by some highlighter functionality in MPS (AsyncFilterRunner.runTasks).

    Edit: I think it may be converting references to code (such as TypeLattice.java:847) into clickable links.

    opened by sander2 1
  • Binding generated data

    Binding generated data

    Using strings that are generated by Java code are handled incorrectly. This works:

    assert MyLattice.randomString() == "test"

    But this does not:

    x := MyLattice.randomString()
assert x == "test"

    You explained that generated data can never be returned from a pattern function, but that it should be allowed to be bound to temporary variables. However, during compilation, the code is transformed in such a way that all variables are returned as part of a generated function. Thus, the transformed code is illegal and does not work.

    opened by sander2 1
  • return from within match

    return from within match

    Return statements in pattern matches in lattice code don't work as I'd expect them to. This works:

    def lookupField(s : TypeLattice, fieldName : string) : TypeLattice = {
    TypeLattice ret = Invalid;
    match s with {
        case StructType(structName, fields) => {
            if (fields.containsKey(fieldName)) {
                ret = fields[fieldName];
            }
        }
    };
    return ret;
}

    but this doesn't:

    def lookupField(s : TypeLattice, fieldName : string) : TypeLattice = {
    match s with {
        case StructType(structName, fields) => {
            if (fields.containsKey(fieldName)) { return fields[fieldName]; }
        }
    };
    return Invalid;
}

    I think that since match is compiled into an anonymous function, a return inside match actually assigns the value to result of the match expression, rather than to the result of the function. This might be intended behavior, but if so, it should probably be documented somewhere

    opened by sander2 1
  • Error while editing code

    Error while editing code

    I received the following error while editing IncA code:

    java.lang.AssertionError: You can't edit unregistered node
	at jetbrains.mps.ide.editor.MPSEditorOpener.doOpenNode(MPSEditorOpener.java:81)
	at jetbrains.mps.ide.editor.MPSEditorOpener.openNode(MPSEditorOpener.java:77)
	at jetbrains.mps.ide.navigation.NavigationSupportImpl.openNode(NavigationSupportImpl.java:54)
	at org.inca.ui.plugin.MouseListener$1.run(MouseListener.java:63)
	at jetbrains.mps.smodel.ActionDispatcher.dispatch(ActionDispatcher.java:84)
	at jetbrains.mps.smodel.ActionDispatcher.lambda$wrap$0(ActionDispatcher.java:105)
	at jetbrains.mps.smodel.LockRunnable.run(LockRunnable.java:60)
	at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:1057)
	at jetbrains.mps.smodel.TryRunPlatformWriteHelper.runWrite(TryRunPlatformWriteHelper.java:103)
	at jetbrains.mps.smodel.WorkbenchModelAccess.runWriteAction(WorkbenchModelAccess.java:98)
	at jetbrains.mps.smodel.ModelAccessBase.runWriteAction(ModelAccessBase.java:64)
	at org.inca.ui.plugin.MouseListener.mousePressed(MouseListener.java:61)
	at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:280)
	at java.awt.Component.processMouseEvent(Component.java:6545)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3325)
	at java.awt.Component.processEvent(Component.java:6313)
	at java.awt.Container.processEvent(Container.java:2237)
	at java.awt.Component.dispatchEventImpl(Component.java:4903)
	at java.awt.Container.dispatchEventImpl(Container.java:2295)
	at java.awt.Component.dispatchEvent(Component.java:4725)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4889)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4523)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4467)
	at java.awt.Container.dispatchEventImpl(Container.java:2281)
	at java.awt.Window.dispatchEventImpl(Window.java:2746)
	at java.awt.Component.dispatchEvent(Component.java:4725)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764)
	at java.awt.EventQueue.access$500(EventQueue.java:98)
	at java.awt.EventQueue$3.run(EventQueue.java:715)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90)
	at java.awt.EventQueue$4.run(EventQueue.java:737)
	at java.awt.EventQueue$4.run(EventQueue.java:735)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:734)
	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:719)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:664)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:363)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
    opened by andrepacak 0
  • Differential data-flow evaluation in the backend

    Differential data-flow evaluation in the backend

    This is a research endeavour. The idea is to create an alternative evaluation strategy in the RETE network that is based on differential dataflow. The technique is best described in "Differential Dataflow - F McSherry, DG Murray, R Isaacs, M Isard - CIDR, 2013".

    This issue is also tracked on the Viatra Queries issue tracker https://bugs.eclipse.org/bugs/show_bug.cgi?id=543400.

    enhancement 
    opened by szabta89 0
  • Use IncA as a test suite for VIATRA Query runtime

    Use IncA as a test suite for VIATRA Query runtime

    The complex recursive queries provided by IncA would be a good candidate for testing the VIATRA Query runtime for regressions. For this to work, the following steps are necessary:

    • [ ] Gradle should load VIATRA query plug-ins from a maven repository (like https://repo.eclipse.org/content/groups/viatra/)
    • [ ] For easier debugging, there should be an alternative pull in the VIATRA jars as local dependencies, e.g. jars or Eclipse projects
    • [ ] Include the inter-procedural points-to analysis in the test suite.
    • [ ] Set up a build job that executes these tests in a location that is visible to VIATRA committers, if possible on ci.eclipse.org; or if necessary at a build server provided by IncQuery Labs

    I try to help with the related issues as I have time (most likely in January).

    opened by ujhelyiz 1
  • The type com.mbeddr.mpsutil.inca.core.runtime.plugin.MPSQuerySpecificationHints cannot be resolved.

    The type com.mbeddr.mpsutil.inca.core.runtime.plugin.MPSQuerySpecificationHints cannot be resolved.

    Rebuild fails for this IncA project: Experiment1/TestPCFnew in https://github.com/seba--/inca-experiments/tree/import-failure

    Error stack:

    [jetbrains.mps.make.ModuleMaker] Cycle #1: [[Experiment1 [solution]]]
[jetbrains.mps.make.CompilationErrorsHandler@5a580b5d] Compilation problems
[jetbrains.mps.make.CompilationErrorsHandler@5a580b5d] Modules: [Experiment1 [solution]];
Classpath: classpath {
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/capsule-0.4.0-20170621.132553-7.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.emf.common_2.13.0.v20170609-0707.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/platform.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/ecj-4.7.2.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/languageDesign/jetbrains.mps.lang.smodel.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/util.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/extensions.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.osgi_3.12.50.v20170928-1321.jar
	file-cp: /Users/seba/projects/inca/code/languages/org.inca.core/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-closures.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-editor.jar
	file-cp: /Users/seba/projects/inca/code/solutions/org.inca.data.runtime/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/languageDesign/jetbrains.mps.lang.traceable.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-messaging.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/languageDesign/jetbrains.mps.lang.core.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/platform-impl.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/baseLanguage/jetbrains.mps.baseLanguage.scopes.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-annotations.jar
	file-cp: /Users/seba/projects/inca-experiments/solutions/Experiment1/classes_gen
	file-cp: /Users/seba/projects/inca-experiments/languages/PCF/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/baseLanguage/jetbrains.mps.baseLanguage.collections.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.query.runtime.matchers_2.0.0.2018.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/jre/jdk/Contents/Home/jre/lib/charsets.jar
	file-cp: /Users/seba/projects/inca/code/solutions/org.inca.gp.runtime/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-collections.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/jre/jdk/Contents/Home/jre/lib/ext/jfxrt.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/asm-all.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-platform.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.query.runtime.base_2.0.0.2018.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-openapi.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.query.runtime.rete.recipes_2.0.0.2018.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/languageDesign/jetbrains.mps.lang.structure.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.query.runtime.base.itc_2.0.0.2018.jar
	file-cp: /Users/seba/projects/inca/code/solutions/org.inca.hints/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-core.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.emf.ecore_2.13.0.v20170609-0707.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-editor-api.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.xtext.xbase.lib_2.12.0.v20170518-0757.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-behavior-api.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.core.runtime_3.13.0.v20170207-1030.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/openapi.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.emf.codegen.ecore_2.13.0.v20170609-0928.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/netty-all-4.1.13.Final.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/jre/jdk/Contents/Home/jre/lib/rt.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/jre/jdk/Contents/Home/jre/lib/jsse.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/languageDesign/jetbrains.mps.lang.modelapi.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.query.runtime_2.0.0.2018.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/jre/jdk/Contents/Home/jre/lib/jce.jar
	file-cp: /Users/seba/projects/inca/code/solutions/org.inca.fun.runtime/classes_gen
	file-cp: /Users/seba/projects/inca-experiments/languages/FeatherweightJava/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/baseLanguage/jetbrains.mps.baseLanguage.closures.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/commons-imaging-1.0-RC.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/jdom.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/xstream-1.4.8.jar
	file-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/guava-21.0.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/picocontainer.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.collections_9.0.0.v20170920-0536.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-tuples.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/annotations.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-editor-runtime.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.transformation.evm_2.0.0.2018.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-behavior-runtime.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-logging.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/log4j.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.xtext.xbase_2.12.0.v20170519-0752.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.core.databinding.observable_1.6.100.v20170515-1119.jar
	jar-cp: /Users/seba/projects/inca/artifacts/com.mbeddr.platform/com.mbeddr.mpsutil.common/languages/group.common/com.mbeddr.mpsutil.common.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/baseLanguage/jetbrains.mps.baseLanguage.javadoc.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-boot-util.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.addon.databinding.runtime_2.0.0.2018.jar
	file-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.util/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/trove4j.jar
	file-cp: /Users/seba/projects/inca-experiments/solutions/FeatherweightJavaImporter/classes_gen
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/mps-icons.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.viatra.query.runtime.rete_2.0.0.2018.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/platform-api.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/languages/baseLanguage/jetbrains.mps.baseLanguage.jar
	jar-cp: /Applications/MPS 2018.1.app/Contents/lib/forms_rt.jar
	jar-cp: /Users/seba/projects/inca/code/solutions/org.inca.core.runtime/lib/org.eclipse.equinox.common_3.9.0.v20170207-1454.jar
}

[jetbrains.mps.make.CompilationErrorsHandler@5a580b5d] TestPCF/BottomUp_TypeOfReference_WrappedQuerySpecification.java : The type com.mbeddr.mpsutil.inca.core.runtime.plugin.MPSQuerySpecificationHints cannot be resolved. It is indirectly referenced from required .class files (line: 1)
[jetbrains.mps.make.CompilationErrorsHandler@5a580b5d] 

TestPCF/BottomUp_TypeOfReference_WrappedQuerySpecification.java : The import com.mbeddr.mpsutil.inca cannot be resolved (line: 5)
TestPCF/BottomUp_TypeOfReference_WrappedQuerySpecification.java : The import com.mbeddr.mpsutil.inca cannot be resolved (line: 6)
TestPCF/BottomUp_TypeOfReference_WrappedQuerySpecification.java : The import com.mbeddr.mpsutil.inca cannot be resolved (line: 10)
... (goes on like that)
    opened by seba-- 0
  • investigate how to introduce inline functions

    investigate how to introduce inline functions

    For code organization purposes, it often makes sense to build up the analysis from smaller analysis functions. However, the small pieces may introduce a large number of tuples because of potential cross product among the parameters. It would make sense to mark function as inline, so that at runtime the constraints of the function would be inlined into the caller.

    opened by szabta89 0
Owner
Tamas Szabo
Principal language engineer @ Workday / PhD in computer science / mountain biker / crossfitter
Tamas Szabo
GitHub
Mewl, program in cats' language; A just-for-fun language

Mewl The programming language of cats' with the taste of lisp ?? What,Why? Well, 2 years ago in 2020, I created a esoteric programming language called

Palash Bauri 14 Oct 23, 2022
CLI program written in Rust to anonymize DICOM files

dicom-anonymizer CLI program written in Rust to anonymize DICOM files anonymizer 0.1.0 Domenic Melcher USAGE: anonymizer [OPTIONS] <FILE> ARGS:

Domenic Melcher 2 May 30, 2022
Open source bible study program on Linux!

Open Witness Library Open Witness Library is a program to read articles that carries God's true name. Warning This branch is outdated, please refer to

Wellington Júnior 5 Jun 29, 2023
📱️🚫️🌝️💾️ 3FakeIM is a joke program meant to imitate various fictional characters, and the "[CHARACTER] CALLED ME AT 3:00 AM" clickbait trend, while poking fun.

3FakeIM ??️??️??️??️ 3FakeIM is a joke program meant to imitate various fictional characters, and the "[CHARACTER] CALLED ME AT 3:00 AM" clickbait tre

Sean P. Myrick V19.1.7.2 2 Jul 3, 2023
An RPC framework developing tutorial

Mini Lust 系列教程 好奇如何从零造出来一个 RPC 框架？本教程将带你一步一步写出来一个 Rust 版 Thrift RPC 框架。 教程说明 从第二章开始每章节都会附带代码。 这个代码是在上一章节的基础上写的，文档里一般会告诉你增加了哪些东西，但是如果你想详细地对比到底哪里变动了，可以自

null 454 Dec 30, 2022
A recommender systems framework for Rust

Quackin Release the quackin! ?? Quackin is a recommender systems framework written in Rust. This is a young project, which means two things: There wil

Christopher Vittal 8 Dec 8, 2021
Safe Rust bindings to the DynamoRIO dynamic binary instrumentation framework.

Introduction The dynamorio-rs crate provides safe Rust bindings to the DynamoRIO dynamic binary instrumentation framework, essentially allowing you to

S.J.R. van Schaik 17 Nov 21, 2022
Integra8 rust integration test framework Rust with a focus on productivity, extensibility, and speed.

integra8 Integra8 rust integration test framework Rust with a focus on productivity, extensibility, and speed. | This repo is in a "work in progress"

exceptional 3 Sep 26, 2022
Rust bindings to the dos-like framework

dos-like for Rust   This project provides access to Mattias Gustavsson's dos-like framework, so as to write DOS-like applications in Rust. How to use

Eduardo Pinho 9 Aug 25, 2022
A developer-friendly framework for building user interfaces in Rust

Reading: "Fru" as in "fruit" and "i" as in "I" (I am). What is Frui? Frui is a developer-friendly UI framework that makes building user interfaces eas

Frui Framework 1.1k Jan 8, 2023
A backend framework for building fast and flexible APIs rapidly.

Andromeda Andromeda is a backend framework for Rust, to simplify the development of the kinds of basic API services that we developers have to build s

Framesurge 7 Dec 28, 2022
🧪 The versatile and intuitive memory hacking framework.

?? hax ?? About hax is a Rust crate designed to make memory hacking, game hacking, cheat development, and any other low level memory based development

null 16 Dec 18, 2022
A minimal boilerplate for Astro / Vite with the Nannou creative framework (Rust → WASM). Supports multiple sketches + hot-reload.

Astro x Nannou Starter astro-nannou-demo-1c.mov ?? Try it online! # 0a. Rust language tools open https://www.rust-lang.org/tools/install # 0b. wasm-p

Julian Cataldo 4 Jan 4, 2023
Grebuloff is an experimental addon framework for Final Fantasy XIV.

Grebuloff Grebuloff is an experimental addon framework for Final Fantasy XIV. It introduces a new concept of what plugins can be, focusing on enabling

Ava Chaney 5 Jun 11, 2023
Indeed, an ORM library, not a framework, written in Rust

Ormlib Indeed, an ORM library, not a framework, written in Rust Features The main idea that I put into my ORM library is a minimum of stupid code and

Evgeny Igumnov 5 Sep 4, 2023
Moving to the new Arbiter framework to test Portfolio.

Stable Pool Simulation The simulation in this repository is intended to demonstrate a basic simulation created with the Arbiter framework. To do so, w

Primitive 6 Sep 15, 2023
Manas project aims to create a modular framework and ecosystem to create robust storage servers adhering to Solid protocol in rust.

मनस् | Manas Solid is a web native protocol to enable interoperable, read-write, collaborative, and decentralized web, truer to web's original vision.

Manomayam 17 Oct 5, 2023
Retina is a network analysis framework that supports 100+ Gbps traffic analysis on a single server with no specialized hardware.

Retina Retina is a network analysis framework that enables operators and researchers to ask complex questions about high-speed (>100gbE) network links

Stanford Security Research 73 Jun 21, 2023
A pure, low-level tensor program representation enabling tensor program optimization via program rewriting

Glenside is a pure, low-level tensor program representation which enables tensor program optimization via program rewriting, using rewriting frameworks such as the egg equality saturation library.

Gus Smith 45 Dec 28, 2022
Incremental, multi-version remote backup tool for block devices.

bsync Incremental, multi-version remote backup tool for block devices. The on-disk backup format is a SQLite database and I've been dogfooding this on

Heyang Zhou 7 Aug 21, 2022