matiasvara / bcoolexamples

This project contains BCOoL examples which includes the specification of a BCOoL operator plus a model. The BCOoL specification can be used to coordinate the models.

Hi there 👋

I am Matias from Argentina and I live in France since 2011. I enjoy programming and designing software systems. My main project is Toro that I have started in 2003. This is a unikernel written in Freepascal. General speaking, I enjoy working on operating system development in which I have to write software that interacts with the hardware. Also, I like to try new things.

• 🔭 I’m currently working on development of Toro unikernel
• 🌱 I’m currently learning how to leverage on formal methods to improve software development
• 🤔 I’m looking for help with Toro
• Some of my contributions

I enjoy writing articles, making videos and giving talks about different subjects. Those activities help me to understand better why and what I am doing something. This is a non-exhastuive list of articles and talks:

Talks

Running MPI applications on Toro unikernel

Improving the Querying of VCPU Statistics in Xen

Verifying the Conformance of a Driver Implementation to the VirtIO Specification

ToroV, a kernel in user-space, or sort of

Building a Cloud Infrastructure to Deploy Microservices as Microvm Guests

Leveraging virtiofs and vsocket in toro unikernel

Speeding up the Booting Time of a Toro Appliance

ToroKernel at FaMAF

Reducing CPU usage of a Toro Appliance

Articles

Running MPI applications as an unikernel

Profiling and Optimizing Toro unikernel with Qprofiler

Debugging by using QEMU trace-events

bcoolexamples's Issues

Problem in the qvto when translating some correspondence matching expressions

The qvto generation fails when a matching correspondence includes an expression like: "s.name = "something"". In this case, there is a bug in the translation from a GExpression to an String. The bug is not fixed yet.

Problem during the CCSL generation if the qvt was regenerated

The following problem was observed if we have regenerated the qvto and we tray to regenerate the CCSL:

"Java method invocation error 'public java.util.Set fr.inria.aoste.timesquare.ecl.qvto.helper.EclQVToHelper.getLibObjects(java.lang.String)'"

In the second eclipse workspace, we get the following error:

This exception is shown in the first eclipse workspace:

A temporal solution is to manually edit the qvto and replace the lines where TFSMMoC.lib is imported by replacing the "resource" to "plugin". Then, the line becomes:

'platform:/plugin/org.gemoc.sample.tfsm.moc.lib/ccsl/TFSMMoC.ccslLib'

Wrong parameter order in the generated CCSL

The order of the parameters in the CCSL relation is wrong. For instance, in the following Figure, the order of the parameters in the Causality relation are inverted

For now, the order of the parameters should be manually corrected. We work for fixing the bug.

The NSUri in the generated QVTo is wrong

In some specific case, the transformation fails to get the NSUri of the imported interfaces, and then, the generated qvto is wrong or directly empty. This problem depends on how the ECL specification imports the metamodel (.ecore). We give a partial list of tips to avoid this problem:

• The URI in the ECL must be the first line, with no commented lines before.
• The URI must be imported as "platform:/plugin...'. Using 'resource' may get an exception.

This list is partial, so that don't hesitate to other solutions.

Reuse of Coordination Rules

Sometime the specification of a coordination rule can become complex. In such cases, I want to reuse a coordination rule to avoid rewritten same code. First, coordination rules must have a name, second, it must be possible to define that two coordination rules are the same.

Matias

Problem in qvto when .ecore is imported in the ecl

In some cases, in the generated qvto, the metamodels are not correctly imported. This occurs when the .ecl imports an .ecore. The transfo should check if the import is a .ecore and then return the corresponding NSURI.

DSE proposed in the Operator are not filtered by the interface

When a new operator is defined, the proposed DSE are not filter by the interface. This become a problem if there is DSE with the same name. In such case, only one is proposed.

Matching by using a java method

It should be possible to match elements by sing an external method in java. This would make possible to match events by relying on a dictionary.

Import into GEMOC studio leads to Errors.

I wanted to run the examples mentioned on the GMCO webpage but I seem to be missing some bundles/dependencies.

Steps to reproduce:

1. Download the newest version of GMCO studio --> V3.3.0 - 2021/07/28
2. Clone this repository.
3. File < Import < Existing Projects into Workspace to load the cloned samples.

Here is a screenshot of some errors:

Can you give me a hint on how to resolve these errors? I would really like to try the BCOooLExamples myself.

Thanks in advance!