lf-lang / lingua-franca Goto Github PK

The LF grammar defines a special type time for the declaration of parameters. I found it suprising that this is limmeted to only paramters. To make the use of the time type more consistend, I propose to extend this notion to all places in the Grammar where types are used. This includes state but also ports and actions.

We need have something akin to a main function; execution can only begin when the top-level composite has been created. I propose to introduce a keyword for it. E.g.:

composite Top() {
   // stuff
}

start new Top();

I noticed that we don't have a constructor for composite in SimpleTest.lf. Why?

The lingua-franca repository should have a LICENSE.md file.

See https://help.github.com/en/articles/adding-a-license-to-a-repository

I suggest using the BSD 2-Clause License that is listed on the Github website as opposed to the Ptolemy license so that the wording is precisely the same as the much more common BSD 2-Clause License.

However, this is just a minor suggestion, using the Ptolemy license would be fine.

In the past, each source file has had a license at the top of the file. This was in part because portions of Ptolemy would be reused and the license file not included. It might be sufficient for each file include a single line that refers to the license file. However, adding this text to each file is optional and can probably be skipped for now.

BTW - It is an open question as to whether generated files should have a license. If the generated files do have a license, then it is possible to redistribute those files under the license. If the generated files have no license, then they are copyrighted (in the US) and possibly not easily redistributed. However, a license could be added to the generated files by hand.

BSD 2-Clause License

Copyright (c) 2019, Industrial Cyberphysical Systems (iCyPhy) All rights reserved.

Redistribution and use in source and binary forms, with or without modification, 
are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, 
this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, 
this list of conditions and the following disclaimer in the documentation 
and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.

This is currently only an issue in Eclipse because the ScopeProvider uses the entire resource set, which encompasses all files in the project. It should exclude files that are not imported. This issue is just meant as a reminder to self for fixing this.

I think it would help if we'd have some consistent notation for the following concepts:

• logical time
• physical time
• delay
• deadline

I would propose to use lower case for logical notions and capitals for physical ones. How about: logical time (t), physical time (T), delay (d), deadline (D)?

Response to Andrés comments:

We're somehow missing explaining the problem we're trying to solve in this paper. We barely addressed the usefulness of having a well-defined (deterministic) MoC governing the execution. Inter-language portability, which I presume is why you guys settled on this name Lingua Franca, we don't even mention.
Also, there's certainly a lot of work annotating code with additional guarantee's (usually a bunch of cumbersome annotations via some manifest or something). Why is our approach better?
I propose to restructure this intro a bit. I like the start with Hewitt actors vs OOP, because it sets a context and already addresses a problem (concurrency).
I would follow this up with an (abstract) overview of the problems with the state of the art. Hewitt actors (nondeterminacy, no timing), is already there.
Missing: usual annotations very unintuitive, difficult to write, and with a zoo of different environments (need for a ``lingua franca'' to combine in a structured fashion).
Perhaps I would follow this up directly proposing our LF, instead of discussing related work.

I agree that we can do a better job illustrating the problem we're solving (reference an example?), but I'd like to limit the scope of the discussion to actors, timestamps, and determinism in the introduction. We should not discuss detailed aspects of the language here. We're not even settling on a syntax in this paper yet, and the polyglot approach, albeit innovative, is not a solution to the problem in itself; I think it would be better to save these details for the tool chain section. I agree that it would be great to compare our approach to other frameworks that use cumbersome manifests, but I think this discussion belongs in the related work section. Could you take the lead on writing the text? We can reorganize things later as we see fit.

When I make a change to, say, reactor_threaded.c and recompile, this change is not reflected in the result. It appears there is some caching going on; not quite sure.

Currently, we're only checking for uniqueness of reactor class names at the file level. If we redefine a reactor class that is already defined in an imported file, we don't catch that, and instead it triggers stack overflow in the code generator.
Here's an example that exhibits the problem:

target C;
reactor HelloWorld {
    timer t;
    reaction(t) {=
        printf("Hello World.\n");
    =}
}

target C;
import HelloWorld.lf;
main reactor HelloWorld {
    a = new HelloWorld();
    b = new HelloWorld();
}

We probably want a more expressive import statement along the lines of:
import X from Y as Z to rename imported reactor classes.

Aside from that, uniqueness checks must be done across imports. Not sure how to do that. The discussion here looks useful.

In org.icyphy.linguafranca.diagram, after updating Eclipse with Kieler Lightweight Diagrams - Developer Resources and Examples from http://rtsys.informatik.uni-kiel.de/~kieler/updatesite/ and added all of Elk from https://build.eclipse.org/modeling/elk/updates/nightly, I'm still seeing build errors in

org.icyphy.linguafranca.diagram/src/org/icyphy/linguafranca/diagram/synthesis/LinguaFrancaSynthesis.xtend

Description Resource Path Location Type
org.eclipse.elk.alg.layered.p4nodes.bk.EdgeStraighteningStrategy cannot be resolved to a type. LinguaFrancaSynthesis.xtend /org.icyphy.linguafranca.diagram/src/org/icyphy/linguafranca/diagram/synthesis line: 33 /org.icyphy.linguafranca.diagram/src/org/icyphy/linguafranca/diagram/synthesis/LinguaFrancaSynthesis.xtend Xtend Problem

and
The method or field EdgeStraighteningStrategy is undefined LinguaFrancaSynthesis.xtend /org.icyphy.linguafranca.diagram/src/org/icyphy/linguafranca/diagram/synthesis line: 81 /org.icyphy.linguafranca.diagram/src/org/icyphy/linguafranca/diagram/synthesis/LinguaFrancaSynthesis.xtend Xtend Problem

the first is caused by

import org.eclipse.elk.alg.layered.p4nodes.bk.EdgeStraighteningStrategy

the second by

rootNode.setLayoutOption(LayeredOptions.NODE_PLACEMENT_BK_EDGE_STRAIGHTENING, EdgeStraighteningStrategy.IMPROVE_STRAIGHTNESS)

Should these lines be commented out?

I updated xtext/README.md to include instructions for updating Eclipse with the Kieler plugins/features. Perhaps I'm missing the correct steps?

In lingua-franca/compiler, running "make setup" downloads accessors using svn and repo.eecs. Instead, shouldn't git and https://github.com/icyphy/accessors be used?

If the repos are the same, then maybe a comment should be displayed that says this?

bash-3.2$ make setup
svn co https://repo.eecs.berkeley.edu/svn-anon/projects/terraswarm/accessors/trunk/accessors
A    accessors/web
A    accessors/web/net

Q1- You say: "A composite is a reactor ..."
So, we can have reactions in a composite?

Q2- You separated action from inputs, as a side effect of some action of the reactor itself.
Why do we need this?
(By the way, this definition is not included in the principles, but that should be ok, it is right above them).

Q3- For each event (input, action, clock) we have a reaction in the body, right?

Is Lingua Franca now the name for the timed actors? For me, it was the language that
describes them and is able to work with different target languages. Are we mixing here two
orthogonal concepts?

I would reserve lingua franca for the language. However, then we probably need a new name for the actor semantics. And introducing two new names in one paper is a little bit on the high side.

Martin

For logical time we have get_logical_time and get_elapsed_logical_time. For physical time the elapsed value would be interesting as well. Comments?

Other actor frameworks can be mentioned in the introduction. That's where we can immediately distinguish our approach as a segue into a description of what our definitions are. In the relation work section, we need to compare ourselves to other programming languages that incorporate timing specs...

Section 3, third paragraph has unreadable sentences.

Section 4 is the main place to describe why and how LF is deterministic I guess. I'll read it carefully when you are done.

I looked in to building and test the code generator output.

I did not find an obvious example of using Xtext to generate C/C++ and compile it. Does anyone know of an example?

I think the way to go about this would probably be to use Ant or Maven to build and execute the generated files. Ant might be easier to use than Maven. Eclipse has fairly good infrastructure for executing Ant. It should be fairly easy to invoke an Ant target and then check the subprocess exit code.

As far as testing the code generator, it might be helpful if the generated test cases would output test results output in a format that Eclipse would understand. I'm not sure what format Eclipse expects from the tests.

I did something similar with the Ansible and Jenkins so that when Ansible was run, it would generate output using the JUnit xml format that was understandable by Jenkins.

It would be good to set up continuous integration for lingua-franca. The idea here is to be sure that everything builds properly and that there is an update repository so that people could eventually use lingua-franca without checking out the repo itself.

One way to do this would be to use Maven to build any Eclipse artifacts and then use Travis to run Maven.

See https://www.eclipse.org/Xtext/documentation/350_continuous_integration.html#maven-tycho-hints

There is an example repo at https://github.com/xtext/maven-xtext-example

It might be possible to use the Maven archetype at https://github.com/fuinorg/emt-xtext-archetype

Maven archetype that creates an Xtext project with a multi module Maven layout and Tycho (manifest-first approach). The archetype was created using the Maven Xtext Example.

The idea here would be to use the archetype to build a fake project that has the layout of the current lingua-franca project and then copy the Maven and Tycho files in to the real repo.

I used Maven to build Triquetrum. There are random notes at https://wiki.eecs.berkeley.edu/ptexternal/Main/EclipseAndTycho See also https://wiki.eclipse.org/Triquetrum/Releng

I found that doing the initial setup had a fairly steep learning curve (looking at examples helped greatly) and eventually it all worked.

As the lingua-franca repo is private, to use Travis would require using https://travis-ci.com instead of .org. Fortunately, it it possible for iCyPhy to use the travis-ci.com via the Travis educational effort. This access might already be set up.

When a deadline is violated, the event should be suppressed and it's payload redirected to the action associated with the deadline. This action is to trigger any error-handling reactions at the current logical time (i.e., at the same microstep).

Map LF threads to cores either by providing a pthread emulation API in Patmos or have Patmos specific code in LF. In the initial version use plain, external shared memory for communication.

I'd suggest we just use simple braces instead of {- -}. The use of dashes doesn't really prevent lexing ambiguity (since you can have an array starting with e.g. {-10 in C, as well as any characters in strings and comments) but I think it makes typing significantly harder and therefore the language much less friendly to use.

We changed the C code generator to produce target code in src-gen and executables in bin (not one level up); the other code generators should do something similar.

Travis is unable to build the LF compiler because it cannot authenticate https://plugins.gradle.org/m2/com/github/jengelman/gradle/plugins/shadow/5.1.0/shadow-5.1.0.pom

There's a message from Gradle that suggests this has something to do with their dropping of HTTP support and/or a race condition in Java's SSL implementation:
https://status.gradle.com/?utm_source=embed

I don't see this problem on my own machine, which uses Java 8.

Currently, preamble blocks can defined within the scope of a reactor definition. As such, it looks more like a constructor. It seems odd to call it preamble. Moreover, if we want inheritance in LF, it seems perfectly reasonable to have constructors, even if the target language doesn't have them. We had the keyword constructor before, and we've reverted to preamble at some point, but I don't recall why. It doesn't seem like a satisfactory solution to me. To me, preamble is something that should have global scope, which is something we're not even allowing currently.

Concrete syntax proposal:

• give preamble global scope (we could potentially call it global)
• change current "local" preamble into a target language code block delimited by {= and =} but without the preamble keyword; the functionality would remain unchanged for the C target; it be useful for defining class functions in OO languages
• add a constructor {= ... =} block to reactor definitions; this would map to regular constructors in OO languages and, if used, would have the same functionality in C as the current preamble provides

This is currently not happening. Instead, when executing the generate C code, an error like this is thrown, which is not very descriptive of the problem:

/usr/bin/ld: /tmp/ccf537PH.o: in function `initialize':
ImportedC.c:(.text+0x15bf): undefined reference to `__initialize_trigger_objects'
/usr/bin/ld: /tmp/ccf537PH.o: in function `next':
ImportedC.c:(.text+0x1901): undefined reference to `__start_time_step'
/usr/bin/ld: /tmp/ccf537PH.o: in function `main':
ImportedC.c:(.text+0x1cdc): undefined reference to `__start_timers'
collect2: error: ld returned 1 exit status

We have used delay actors and delays associated with connections interchangeably during our discussions, but it occurred to me that having a delay actor (one that has a reaction that passes trough data with some delay) appears inconsistent with the requirement that all reactions be instantaneous. Note that there are cases where the scheduler does not have to wait for physical time to catch up with a logical time delay, and physical time being ahead of logical time upon the release of a delay does not always imply a deadline miss; so the deadline attribute cannot be used to decorate the logical time delay reaction (it would be too restrictive).

Therefore, I propose to abandon the use of the delay actor and solely associate delays with connections henceforth.

I would like to split the repo into two:

(1) lingua-franca: contains all the source code and will be made public in the (near) future

(2) lingua-franca-paper: contains the paper(s) source and all the issues we use for internal discussion

This split can be done with a copy (fork) and then deleting the not needed material. I would like to keep the history for both repos.

As CapeCode expects for each JS actor or composite to be in its own file, the compiler shall spill out one file for each actor, using its name.

This has been an on-going discussion, but we still haven't fully resolved this question.

Arguments for inclusion:

1. It gives a better approximation of the point-to-point delay between sensing and actuation.
2. The actuation delay that is an intrinsic property of the component, independent of its environment, while other delays that factor into the deadline are due to upstream components. For the sake of compositionality, one could could argue that the only delay that should be incorporated in the deadline should be the actuation delay. Reasoning along these lines, one could argue that that exclusion of the actuation delay implies that D should always be zero.

Arguments for exclusion:
3. It is hard to know what the actual actuation delay is.
4. It is better to report a deadline miss prior to actuation, which could potentially be harmful if it is carried out too late.
5. We do not account for the delay between the physical sensing and the reporting of the sensed value either (but we potentially could add a constant here too?).

While I agree with argument 4, I'm doubtful as to whether it supports the case for excluding actuation delays; if the actuation delay is known, the actual time of actuation is also known before its release (in which case the scheduler could skip it).

Looking forward to your feedback...

We now have a standalone compiler that can be invoked as follows:

lfc [FILE]

Or, if you didn't add bin to your PATH"

cd bin
./lfc [FILE]

The output of lfc is target code. Shouldn't we want lfc to invoke the target compiler and produce an executable?

Deadlines are associated with reactions. How do we express them?
The reaction decl is a pretty crowded syntactically already, so it might be better to add an annotation in the reactor decl, e.g.:

reactor Punctual {
  input x:int;
  deadline foo 10 ms;
  reaction foo(x) {
    // do something
  }
}

But perhaps it makes more sense for the deadline to be determined on the level of the composite; after all, the deadline is probably application specific and thus is likely unknown until integration.

If we opt for this latter approach, we could have:

x = new Punctual();
deadline(x.foo, 10 ms);

I think I'm in favor of the last option.

This is the main reason why all of the C++ target tests currently fail. run-lf-tests calls all test binaries with the comand line option -timeout 1 sec. This option, however, is not supported in the C++ target. The option there is called --timeout (with two dashes) and does not expect a separate unit. The reason for this is that the CLI11 library that I use for parsing arguments only supports "standard compliant" arguments.

While we probably should have a discussion on if and how CLI arguments should be aligned between targets, I still think that the tests should respect the command line given in the LF target specification.

An action can have a mindelay as parameters and it can be scheduled with a delay in the schedule function. What is the relation between those? If both are set is the delay then the sum of both or the maximum of both? The current behavior is sum (plus the "error" below).

When using a mindelay in an action then the actual behavior is that the action is scheduled in double the time of the mindelay. Which is not "really" wrong, as the description states "minimum delay". But it feels wrong. What about being able to set the exact logical time delay?

How would you implement a variable delay?

Edward

On 3/6/19 11:11 PM, Marten Lohstroh wrote:

Something like:

actor Delay {
input in:object;
output out:object;
trigger trig(1000):object; // for a delay of 1 second
reaction(in, trig) {-
schedule(trig, in.get());
-}
reaction(trig) -> out {-
set(out, trig.get());
-}
}

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIHnNoViVV9gU6BufVk_Rr-J3o3r6k5bks5vULuMgaJpZM4bfWqv.

--
Edward A. Lee
Professor of the Graduate School and
Robert S. Pepper Distinguished Professor Emeritus
EECS Department, UC Berkeley
http://ptolemy.eecs.berkeley.edu/~eal

Originally posted by @edwardalee in #4 (comment)

Is the distinction between a composite and a reactor necessary? In the xtext compiler that I am working on, this distinction leads to a lot of code duplication, and I can't figure out how to avoid the code duplication. I propose that we drop the composite keyword and just use "reactor".

In the accessors framework, there is no need for a distinction. An accessor can contain other accessors and also have handlers for inputs. This can be pretty convenient, providing a kind of aspect-oriented design. E.g.:

reactor Monitor {
input in;
reaction(in) {
log(in);
}
a = ContainedReactor();
in -> a.in;
}

The above reactor wraps a contained reactor and logs its inputs.
Yes, this could be done by pure composite by containing another Logger reactor.
If we want to keep the composite keyword, then I need some help to figure out how to eliminate the code duplication.

We used to have actor(triggers, ...) inputs, ... -> outputs, ....
Edward expressed a preference for something more descriptive rather than just an arrow. We agreed that the following meets that criterion and is still reasonably compact: actor(triggers, ...) reads inputs, ... writes outputs, ...

A shorter variant that preserves that same meaning would be: actor(triggers, ...) gets inputs, ... sets outputs, ...

Thoughts?

Created this issue to keep track of this discussion.

Not convinced this is a good idea. The way the grammar is set up, we get away with parsing it, but it breaks syntax highlighting: in the statement input input; both occurrences of the keyword are highlighted. I think it looks bad... What's wrong with input in and output out and just disallowing the use of keywords as identifiers?

We're currently using a naming convention to identify main reactors (they must be named "Main"). One problem with this approach is that "Main" is not very descriptive. Alternatively, we could have a modifier 'main' that can be put in front of a reactor definition to indicate its role.

Invoking lfc on a non-existing file results in a weird error message:

lfc TimeLimitC
Exception in thread "main" java.lang.RuntimeException: Cannot create a resource for 'file:/home/marten/git/lingua-franca/xtext/org.icyphy.linguafranca/src/test/C/TimeLimitC'; a registered resource factory is needed
	at org.eclipse.xtext.resource.XtextResourceSet.getResource(XtextResourceSet.java:262)
	at org.eclipse.xtext.resource.SynchronizedXtextResourceSet.getResource(SynchronizedXtextResourceSet.java:25)
	at org.icyphy.generator.Main.runGenerator(Main.java:64)
	at org.icyphy.generator.Main.main(Main.java:45)

It should state that it cannot find the file instead.

We have previously discussed the idea of in lining an open-source target language (#2) grammar into the LF grammar depending on the target statement in the LF code. I'm not sure that we should go down this path. It will get us syntax highlighting, yes, but not much more than that; semantic analysis requires a lot more work (and upkeep, as target compilers evolve).

To get feedback on the LF-code, we don't need it. Once the LF source compiles, to get feedback on the target code, we can first generate code, and then compile it with the target language compiler. The feedback from the target compiler can be related to the original parse tokens to get the line numbers right, after which it can be passed back to the programmer. This approach greatly reduces the amount of work that has to be done in the LF compiler in terms of target language analysis, which was kind of the key idea behind the approach to begin with.

I imagine that this approach will be difficult to implement in a framework like XText, focused primarily on domain-specific language extensions rather than the kind of encapsulation that we're doing with LF (but I might be wrong about this). I can definitely see how this could work via the Language Server Protocol (LSP).

We've been getting some feedback that the clock keyword causes confusion. The keyword is syntactic sugar for specifying future events (without invoking schedule in a reaction). As an alternative, timer has been mentioned, but that seems to fail to capture the potentially periodic nature of the events it prescribes to occur. Thoughts?

Actions need to be in scope in order for a reaction to pass it to schedule. There are two mechanisms through which actions can enter reaction scope: via triggers, listed in between braces -or- via the things the reaction produces, listed after the -> symbol.

Now here's the problem:

action a:int;
reaction(a) {
  schedule(a, 1);
}

This is valid LF code that would compile successfully down to the target, but the reaction code should not be able to call schedule a since it was not listed after the ->. This could become a serious issue when we start to rely on timing analysis to come up with valid schedules that exploit parallelism across logical times.

I think we should trap this error in the target compiler, but for that to be possible we need not one but two scoped elements: one for being triggered and one for being scheduled. In C, we could rely on a convention similar to the one we use to check for presence/absence of inputs.

• Shall we do this?
• If so, what should the suffix of the schedulable action variable be?

[ ] https://help.github.com/en/articles/configuring-automation-for-project-boards

The current version of accessors does not work with Node past 7.x, see icyphy/accessors#3

The issue is that npm 5.x, which shipped with Node 8.x, removes files in node_modules.

However, Node 7.x, which is what was shipped with CapeCode 1.0, does not work with peg:

bash-3.2$ which npm
/Users/cxh/src/ptII11.1.devel/bin/npm
bash-3.2$ npm --version
/Users/cxh/src/ptII11.1.devel/bin/npm: Running /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/npm --version
/Users/cxh/src/ptII11.1.devel/bin/node: Running /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/node /Users/cxh/src/ptII11.1.devel/ven\
dors/node/node-v7.10.1-darwin-x64/bin/npm --version
4.2.0
bash-3.2$ npm run compile
/Users/cxh/src/ptII11.1.devel/bin/npm: Running /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/npm run compile
/Users/cxh/src/ptII11.1.devel/bin/node: Running /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/node /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/npm run compile
npm WARN lifecycle The node binary used for scripts is /Users/cxh/src/ptII11.1.devel/bin/node but npm is using /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> [email protected] compile /Users/cxh/src/lingua-franca/peg
> tsc -b

/Users/cxh/src/ptII11.1.devel/bin/node: Running /Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/node /Users/cxh/src/lingua-franca/peg/node_modules/.bin/tsc -b
client/node_modules/vscode-languageclient/lib/protocolConverter.d.ts:54:54 - error TS2694: Namespace '"vscode"' has no exported member 'DocumentSymbol'.

54     asDocumentSymbol(value: ls.DocumentSymbol): code.DocumentSymbol;
                                                        ~~~~~~~~~~~~~~

client/node_modules/vscode-languageclient/lib/protocolConverter.d.ts:56:57 - error TS2694: Namespace '"vscode"' has no exported member 'DocumentSymbol'.

56     asDocumentSymbols(value: ls.DocumentSymbol[]): code.DocumentSymbol[];
                                                           ~~~~~~~~~~~~~~

client/node_modules/vscode-languageclient/lib/protocolConverter.d.ts:57:76 - error TS2694: Namespace '"vscode"' has no exported member 'DocumentSymbol'.

57     asDocumentSymbols(value: ls.DocumentSymbol[] | undefined | null): code.DocumentSymbol[] | undefined;
                                                                              ~~~~~~~~~~~~~~

client/node_modules/vscode-languageclient/lib/client.d.ts:1:707 - error TS2305: Module '"vscode"' has no exported member 'DocumentSymbol'.

1 import { TextDocumentChangeEvent, TextDocument, Disposable, OutputChannel, FileSystemWatcher as VFileSystemWatcher, DiagnosticCollection, Diagnostic as VDiagnostic, Uri, ProviderResult, CancellationToken, Position as VPosition, Location as VLocation, Range as VRange, CompletionItem as VCompletionItem, CompletionList as VCompletionList, SignatureHelp as VSignatureHelp, Definition as VDefinition, DocumentHighlight as VDocumentHighlight, SymbolInformation as VSymbolInformation, CodeActionContext as VCodeActionContext, Command as VCommand, CodeLens as VCodeLens, FormattingOptions as VFormattingOptions, TextEdit as VTextEdit, WorkspaceEdit as VWorkspaceEdit, Hover as VHover, CodeAction as VCodeAction, DocumentSymbol as VDocumentSymbol, DocumentLink as VDocumentLink, TextDocumentWillSaveEvent, WorkspaceFo\
lder as VWorkspaceFolder, CompletionContext as VCompletionContext } from 'vscode';
                                                                                                                                                                                                           \
                                                                                                                                                                                                           \
                                                                                                                                                                                                           \
                                                                                                   ~~~~~~~~~~~~~~


Found 4 errors.


npm ERR! Darwin 18.5.0
npm ERR! argv "/Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/node" "/Users/cxh/src/ptII11.1.devel/vendors/node/node-v7.10.1-darwin-x64/bin/npm" "run" "compile"
npm ERR! node v7.10.1
npm ERR! npm  v4.2.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] compile: `tsc -b`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] compile script 'tsc -b'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the lsp-lf package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     tsc -b
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs lsp-lf
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls lsp-lf
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/cxh/.npm/_logs/2019-05-20T01_23_45_462Z-debug.log
bash-3.2$ 

The workaround is to install a recent version of node and remove the node_modules directory.

cd lingua-franca/peg
brew install npm
export PATH=/usr/local/Cellar/node/12.1.0/libexec/bin:${PATH}
rm -rf node_modules/
npm install
npm audit
npm run compile
npm install pegjs
npm install -g typescript
pegjs lf.pegjs

For the C target, we stick executables in bin/, but Eclipse doesn't show unless the directory is refreshed in the package explorer. It should be able to trigger a refresh automatically.

If we can specify target language types for ports in LF, we can probably get away with just parsing them as identifiers. The same does not hold for default values; they could, in principle, be any statement in the target language. We might have to delimit them (see #2) or come up with a more sophisticated solution.

LF example at: https://github.com/icyphy/lingua-franca/blob/master/xtext/org.icyphy.linguafranca/src/test/C/ActionError.lf

./DeadlineCThreaded -timeout 3 sec runs forever

Some of the tests listed in test-manifest end with a 'C' which point to a C specific test. I think the 'C' should be removed in all tests to have the same tests across targets. Or is there some other meaning to the 'C' that I don't see?

It might also be beneficial in the future to add the possibility of defining additional target specific tests.

I think it's really important to prevent creating a tight coupling/integration with any particular IDE. There simply is no IDE that rules them all, and people have their own preferences, which is especially relevant given the cultural divides between the communities behind the different languages that we're targeting. My proposal would be to use the Language Server Protocol (LSP) to establish a loose coupling with existing IDEs. I really like the philosophy behind it, and is squarely addresses the problem that we're facing. We would perform all our static analysis in a language server and would write a simple client for each IDE we wish to support. LSP is currently supported by many editors already, and the support is growing. Eclipse, IntelliJ, and Visual Studio are among them, but also VIM and many others.