reolanguage / reo Goto Github PK

The current compiler takes the following steps:

1. reads multiple Treo source files;
2. filters out the protocol components from boundary components;
3. composes the protocol and generates a runtime component for it;
4. wraps all boundary components into a runtime component; and
5. outputs all runtime component.

In this framework, there is always exactly one runtime component generated for the complete protocol. The code for this protocol component may depend on Treo code that may come from any possible Treo source file. Therefore, it is not yet possible to compile individual Treo source files using the current compiler.

The user of the compiler might want recomile quite often. Since most files remain exactly the same between two successive compilations, the compiler should be able to reuse its previous results to save time and energy. Especially for large projects, such efficiency step is very desirable.

To allow the reuse of previous compilations, the user should restrict the number of Treo source files on which the protocol's runtime component depends. In that case, all Treo source files that are not used by the procotol can be compiled independently.

One possible way to restrict the dependencies of the protocol's runtime component is by isolation of part of the protocol, that is, ensure that a part of the protocol does not end up in the same runtime component as the rest of the protocol.

Currently, the user can achieve isolation manually by putting the part of the protocol that needs to be isolated into a fresh boundary component. However, this requires the user to precompile that part of the protocol, and write a wrapper Treo component for that generated protocol code. This refactoring step (of converting a Treo file into an boundary component) is quite labour intensive, and should be automated.

One possible way to automate this refactoring process is it to extend the Treo language and by altering steps taken by the compiler. Essentially, the user should be able to determine which parts of the protocol should be treated by the compiler as isolated components, and which parts may be freely composed and optimized.

We could enable the users to declare which parts are isolated by extending the Treo language as follows: If we wish to use a component, then we use

• the include keyword, if we allow it to be composed with the rest; and
• the import keyword, if we use it as an isolated component.

Create a single separate file that contains a grammar rule that lists all alternative subgrammars for atomic component types. The core grammar can the simply include this grammar file.
This way, we do not need to change the core grammar, when we add a new component type.

I'm on Ubuntu 18.04. I can click through the installer wizard but when it goes to actually install the pack it just hangs and shows no progress.

--> java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-8u242-b08-0ubuntu3~18.04-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)

--> ./reo-installer-1.0.jar
Command line arguments: 
Gtk-Message: 22:17:18.168: Failed to load module "canberra-gtk-module"
Cannot find named resource: 'packsLang.xml' AND 'packsLang.xml_eng'
====================
Installation started
Exception in thread "IzPack - Unpacker thread" java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap')
	at com.izforge.izpack.installer.unpacker.UnpackerBase.logIntro(UnpackerBase.java:253)
	at com.izforge.izpack.installer.unpacker.UnpackerBase.unpack(UnpackerBase.java:285)
	at com.izforge.izpack.installer.unpacker.UnpackerBase.run(UnpackerBase.java:242)
	at java.base/java.lang.Thread.run(Thread.java:834)

Consider the 'limping alternator' protocol:

LA(a,c) {
   sync(a,c)
   syncdrain(a,b)
   fifo1(b,c)
}

It has one source node, a, and one sink node, c. Node b is not in the interface of LM and is therefore hidden. The expected behavior of the limping alternator is empty. That is, any put operation on a and get operation on c are blocked forever. The reason is that hidden node b is a source node that is not connected to any producer (which is the same as saying that it is connected to a silent producer component that does not output any values).

Unfortunately, the current compiler incorrectly compiles the limping alternator as a plain sync channel. The reason is that the compiler applies existential quantification to the data value observed at node b. However, existential quantification is correct only for mixed nodes. In this case, existential quantification simply matches up the different components that produce values at the mixed node. For boundary nodes (i.e., source and sink nodes), existential quantification acts like a generator that produces random data out of thin air.

To correct the problem, the compiler must first prevent applying existential quantification to boundary nodes, and simply generate and unconnected node in the target code. Then, we obtain the desired behaviour.

I am not primarily a java dev so I apologize for any obvious ignorance, but I am following the installation instructions.

I am on Ubuntu 18.04 with:

--> java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-8u242-b08-0ubuntu3~18.04-b08)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)

First I download the jar files:

reo-1.0.jar
reo-runtime-java.jar
reo-runtime-java-lykos.jar

And add them to my CLASSPATH as in the initreo.sh script that comes with the installer:

#!/bin/bash

alias reo="java -jar /home/salotz/Downloads/reo-linux_mac/bin/reo-1.0.jar"

export CLASSPATH="$CLASSPATH:.:/home/salotz/Downloads/reo-linux_mac/bin/reo-runtime-java.jar:/home/salotz/Downloads/reo-linux_mac/bin/reo-runtime-java-lykos.jar"

--> source initreo.sh

Then I cloned the repo so I could get all the examples (following the intro in the docs):

git clone [email protected]:ReoLanguage/Reo.git
cd Reo/examples/intro

--> reo main.treo 
line 9:16 token recognition error at: '#Ja'
line 10:18 token recognition error at: '#Ja'
line 11:17 token recognition error at: '#Ja'
[ERROR] (main.treo:9.22) mismatched input '"Processes.Red"' expecting {'(', '[', '<'}
[ERROR] (main.treo:10.24) mismatched input '"Processes.Green"' expecting {'(', '[', '<'}
[ERROR] (main.treo:11.23) mismatched input '"Processes.Blue"' expecting {'(', '[', '<'}

I also tried another one which can at least compile the treo file:

--> cd Reo/examples/test
--> reo filter_test.treo
--> javac filter_test.java 
filter_test.java:102: error: package nl.cwi.reo.templates does not exist
			           !(nl.cwi.reo.templates.Relations.Odd( $1.peek() ))));
			                                 ^
filter_test.java:108: error: package nl.cwi.reo.templates does not exist
			           nl.cwi.reo.templates.Relations.Odd( $1.peek() )));
			                               ^
filter_test.java:147: error: package nl.cwi.reo.templates does not exist
						     !(nl.cwi.reo.templates.Relations.Odd( $1.peek() )))) break;
						                           ^
filter_test.java:149: error: package nl.cwi.reo.templates does not exist
						     nl.cwi.reo.templates.Relations.Odd( $1.peek() ))) break;
						                         ^
4 errors

Integrate model checking as part of the compilation process.

To implement a primitive component in Treo, the user may use a static Java method, such as

public static void f(Output<String> p) {
   ...
}

The compiler uses this static method by producing a wrapper component that makes a call to the static method f. In this call, the wrapper component passes an instance of a node to the port parameter of f. However, it is not checked whether f is indeed of the above form. A malicious user could have provided the following static function:

public static void g(Port<String> p) {
   \\ Use both p.put() and p.get().
}

The compiler would not complain, and even the generated code would not give a runtime error. This is not desired.

The compiler should be changed such that the wrapper component upcasts the Port passed to the static function to an Output. In this way, function g would give a type error.

Hi, I'm using this compiler for my project but when I use any other channels like lossy sync, fifo, sync drain etc, output java file ends up in a deadlock. Even when I use the example you are providing in introduction file it doesn't work either.
Am I doing something wrong or this is a bug in compiler?!

Or-queue optimization
And-queue optimization
FIFO queue optimization

Attempting to compile the following treo code causes a stack overflow in the QE-method of the Existential class.

import reo.sync;

test() { sync(a, b) }