Languages engaged on generation on 3.2 EAP3 (bug?) Follow

Hi Marco,

I'm certainly interested in what you have found. Would you be willing to share the details, please?

Vaclav

The use case was the one described on LWC11 step 8. at 13, document that you probably know.
I did not download the code, instead I reconstruct the whole example from scratch, but at the end I did not get the Database transient objects, instead I got only the Class objects.

It was here that in the same project I created a smaller test:

• a new language Things with only one concept Thing that have just name (INamedConcept). This language has a generator that generate Java classes using the Thing's name.
  
• a new solution where I have created some Thing and verified that the associated Java classes get created without problems.
  
• a second language with a single concept OtherThing implementing INamedConcept. Here the generator has a root mapping rule that maps a Thing from the first language to OtherThing
  
• than I go back to the solution and add this second language under "Languages engaged on generation", but under transient object I still got only java classes objects.
  

The same languages and solution (apart possible human errors while manually duplicating the same structure) but
with version 3.1.5, it worked at first try: for each Thing I got a java Class node and an OtherThing node under transient object.

If you are not able to reproduce the problem I can send you my working and not working projects.

Sorry for all these posts but the new filter did not allowed myself to post on a single message.

Bye,
Mar

Marco, could you please share your sample project for MPS3.2? Engaged languages are used throughout MPS code, and I've just checked they do get into generation plan. E.g. you could look at test1 model from jetbrains.mps.samples.generator_demo.test_models module, which list demoLang1 as 'engaged' and 'Show Generation plan' action for the model does show the language among those to take part in generation.

Of course, se the attached files.

To be sure, I was afraid because I'm new to MPS, I repeated the same example in parallel on 2 projects step by step, one on 3.1.5 and the other on 3.2EAP3: the first language is called "engaged" (sorry dispite to the name it is not the "Language engaged on generation") and has only one concept that generate to Java classes.

The second language (otherLang) is the engaged one.

However you are right: the generation plan in 3.2 shows the otherLang language (see attached projects) as last step.
Nevertheless the transient objects are not generated in version 3.2 and here you get only nodes generated fromt the first language, see screenshots.

Bye,
Mar



engaged31.tgz (37KB)
engaged32.tgz (42KB)

Marco, I feel generation plan tells us the reason for the behaviour observed. In 3.2, language engaged32 comes first (it's the language model is written in), then come its target languages (BL and related), then comes 'otherLang', which is independent of any other language and thus is left for the end of generation sequence. The moment otherLang gets a chance to look into input model, there's no original node (engaged32.Thing), there are only BL classes, and otherLang does nothing to them.

In 3.1, there were no implicit generation priorities (so engaged32 was deemed 'independent' of any other language, including BL, its target), and there was logic to group as much generators to a single generation step as possible. Thus, engaged32 ran together with otherLang, and latter saw 'Thing' instances in the input model. In 3.2, we've introduced implicit dependencies (so that target languages are respected and run after the source generator has been applied) and changed the way generators are grouped together to improve performance (we lean towards single generator run per step, to get rid of present 'transform until no changes' approach).

To run otherLang together with engaged32, you'd likely need 'run together' (=) priority rule in otherLang's generator. Note, to add the rule, you'll need to introduce dependency from engaged32 generator module. It's advised to use 'Design' dependency kind for this purpose.

Ok, it works! Thanks.

I completely trust you that version 3.2 is better, nevertheless MPS dependencies seem not trivial for a newbie like me. Probably after a while one gets used to.

Bye, Mar

Well, if 'at least a year' does sound like 'a while', then yes, they might get easier to understand some day ;) I'm looking forward to simple dependency story, albeit not sure this goal is feasible given complexity of the task at hand.

In case you are interested in my personal point of view the flag "Language engaged on generation" is not the flag to engaged a language on generation anymore. Languages seems now to be engaged at design level through generator precedence.

In my solution I can only enable/add to the generation plan an already engaged language at design level in case I'm interested in the output of a specific generator.
The list "Language engaged on generation" once called "Language enabled during generation plan" should present to the user only languages engaged at design level instead of all languages.

Nevertheless I think I'm trained enough on engaging languages :-) so I don't need new features in this area.

Bye,
Mar

Important distinction is that priority rules take a chance to affect generation only when the generator mentioned there gets into generation plan by other means (e.g. through used languages, extended generators or 'engaged in generation' as in the case we've discussed). Generator being mentioned in priority rule is not sufficient to include it into generation plan. You may read priority rule in a way 'if there's such generator in generation plan, it should run together/later/earlier than another generator)".