Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » EGL undesirable trim on return template operations
EGL undesirable trim on return template operations [message #1847587] Tue, 02 November 2021 02:00 Go to next message
Samantha Swift is currently offline Samantha SwiftFriend
Messages: 2
Registered: September 2021
Junior Member
Hi,

When importing template operations between EGL files, if the operation ends in a newline or whitespace character, the resulting returned string has this newline trimmed. It is desirable to have the operation return the result of the function including the newline characters. Additionally, when the same function is completed within a single file, the desirable output is produced. The trim only appears apply when the operation is imported.

To replicate the bug, the two simple EGL files are as follows

test.egl
[% import "op.egl"; %]
[%= printLine() %]
x


op.egl
[% @template 
operation printLine() { %]
[% for (i in Sequence{1..3}) { %]

[% } %]
[% } %]


The expected output would be



x


However, it produces
x

  • Attachment: op.egl
    (Size: 0.09KB, Downloaded 45 times)
  • Attachment: test.egl
    (Size: 0.04KB, Downloaded 42 times)
Re: EGL undesirable trim on return template operations [message #1847603 is a reply to message #1847587] Tue, 02 November 2021 09:36 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

Hi Samantha,

This is definitely not the expected behaviour but as far as I can tell, it is consistent across both imported and in-file template operations. It seems to be boiling down to the following behaviour of String's split method which is somewhat unexpected for me.

System.out.println("\r\n\r\nx".split("\r\n").length); // Prints 3
System.out.println("x\r\n\r\n".split("\r\n").length); // Prints 1
System.out.println("\r\n\r\n".split("\r\n").length); // Prints 0


Java 11's String.lines() seems to be more consistent with the behaviour I'd expect so we'll switch to that one shortly.

In any event this only seems to be affecting output regions ([%=%]) where the emitted content ends with new line characters - which is probably why it has gone unnoticed so far.

Best,
Dimitris
Re: EGL undesirable trim on return template operations [message #1847746 is a reply to message #1847603] Fri, 05 November 2021 01:30 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

Hello Dimitris!
Have you created a bug for this one? What would you need as a definitive test case? Or is the inside that you have from above already enough for you? If you have a bug number, can you post it here?
Thanks, JG

[Updated on: Fri, 05 November 2021 01:30]

Report message to a moderator

Re: EGL undesirable trim on return template operations [message #1847749 is a reply to message #1847746] Fri, 05 November 2021 08:44 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

Hi Jörn,

The above is sufficient and I'll try to get this fixed within the next few days.

Best,
Dimitris
Re: EGL undesirable trim on return template operations [message #1847871 is a reply to message #1847749] Wed, 10 November 2021 23:28 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

Hi Samantha and Jörn,

I've had a closer look into this and if we were to change EGL's behaviour as discussed, then the following template

[%=hello()%]World
[%
@template
operation hello(){%]
Hello
[%}%]

which now produces
HelloWorld

will now instead produce
Hello
World

which can potentially break existing EGL generators.

Is the current behaviour a major inconvenience for you or was this an oddity you thought you'd report?

Many thanks,
Dimitris
Re: EGL undesirable trim on return template operations [message #1847872 is a reply to message #1847871] Wed, 10 November 2021 23:44 Go to previous messageGo to next message
Horacio Hoyos is currently offline Horacio HoyosFriend
Messages: 242
Registered: October 2009
Location: Mexico
Senior Member

Hi all,

I am with Dimitris on this one. That change would break a lot of existing code.

My 2 cents: As a "best practice", I tend to make template operations free of any pre/post white space formatting. This makes them easier to reuse in places where the white space is context specific, e.g. level of indentation or separation from other blocks.

Cheers,


Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech

[Updated on: Wed, 10 November 2021 23:50] by Moderator

Report message to a moderator

Re: EGL undesirable trim on return template operations [message #1847873 is a reply to message #1847872] Wed, 10 November 2021 23:58 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

This means we need to fork. I would say it is a bug. I guess what this requires is a major semantic version number change. That is what semver is there for. 'It breaks a lot of things.' as argument for retaining non-orthogonal behaviour eventually leads to the fallacy of 'we have no idea why it does that', because you accrue all the special behaviour.

[Updated on: Wed, 10 November 2021 23:58]

Report message to a moderator

Re: EGL undesirable trim on return template operations [message #1847874 is a reply to message #1847872] Thu, 11 November 2021 00:14 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

Our templates are automatically inferred, so we cannot follow the 'best practice'.
We cannot use the existing behaviour inour inference, because it is inconsistent. We are using templates as they are intended to express blocks of templated text. That is why they exist. If we are to use operations, we might as well drop Epsilon templating.
Re: EGL undesirable trim on return template operations [message #1847875 is a reply to message #1847873] Thu, 11 November 2021 00:19 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

Hi Jörn,

I'm not entirely convinced that this behaviour is accidental as there are actually relevant unit tests (in org.eclipse.epsilon.egl.test.acceptance.operations.template.TemplateOperations) that assert that the expected result does not contain additional new lines, and which broke when I attempted to change to the alternative behaviour. I'm not the original developer of EGL so I can't be entirely sure, but the more I think about it, the more the current behaviour makes sense to me. Under the alternative behaviour to make the hello() template operation not emit the extra new line, one would need to use LaTeX-style tricks such as the following, neither of which looks particularly nice.

[%=hello()%]World
[%
@template
operation hello(){%]
Hello[*
*]
[%}%]


[%=hello()%]World
[%
@template
operation hello(){%]
Hello[%}%]


Best,
Dimitris
Re: EGL undesirable trim on return template operations [message #1847876 is a reply to message #1847875] Thu, 11 November 2021 00:34 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

If you definitely need the alternative behaviour in your templates, there shouldn't be a need to fork. You should be able to subclass EgxModule and EglFileGeneratingTemplateFactory, and override IEglContext's newOutputBuffer() to return a custom output buffer with an overridden printdyn() implementation that adds a second (-1) argument to split as follows.

@Override
public void printdyn(Object o) {
  final String indentation = calculateIndentationToMatch(getLastLineInBuffer());
  final String newLine = getNewline();
  final String[] lines = StringUtil.toString(o).split(newLine, -1); // <- The line you'd need to change
  
  for (int i = 0; i < lines.length; i++) {
    if (i == 0) {
      // Any text before the first newline character should not be
      // placed on a newline nor indented  
      buffer.append(lines[i]);
    } else {
      buffer.append(newLine + indentation + lines[i]);
    }
  }


Best,
Dimitris
Re: EGL undesirable trim on return template operations [message #1847877 is a reply to message #1847875] Thu, 11 November 2021 00:36 Go to previous messageGo to next message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

I understand that this behaviour may be tested, but it is surely inconsistent. In the case we have, the method gives different outcomes based on the context. I cannot see how that is helpful. Either all invocations should receive trim() or none.
Re: EGL undesirable trim on return template operations [message #1847878 is a reply to message #1847877] Thu, 11 November 2021 00:39 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

> In the case we have, the method gives different outcomes based on the context.

Could you please share an example that demonstrates this behaviour so that I can look into this?
Re: EGL undesirable trim on return template operations [message #1847879 is a reply to message #1847587] Thu, 11 November 2021 00:58 Go to previous messageGo to next message
Samantha Swift is currently offline Samantha SwiftFriend
Messages: 2
Registered: September 2021
Junior Member
In our case, the template operation is needed in order to dynamically write content from the model into the lines. Additionally, because the templates are being inferred from a reference, we cannot format them manually to ensure additional spacing. I would say the behaviour is a bug as we cannot ensure a space in all cases.

For example, if an "entity" as described below as 3 "attributes"; foo, bar, boo, a space would be placed after foo and bar but not after boo leading to us never generating correct templates.

[% import "op.egl"; %]
Going to write attributes

[%= printAttributes(entity) %]
These  are cool attributes


[% @template 
operation printAttributes(entity) { %]
[% for (attribute in entity.attributes) { %]
    Cool attribute callled: [%=attribute.name%]

[% } %]
[% } %]


Produces

Going to write attributes

Cool attribute callled: foo

Cool attribute callled: bar

Cool attribute callled: boo
These  are cool attributes
Re: EGL undesirable trim on return template operations [message #1847883 is a reply to message #1847879] Thu, 11 November 2021 07:08 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris KolovosFriend
Messages: 2165
Registered: July 2009
Location: York, UK
Senior Member

Hi Jörn,

Just to be clear, ignoring the empty new lines has nothing to do with @template operations; the behaviour comes from [%=%] instead. Therefore, if you replace [%=hello()%] with [%out.print(hello());%], the following template

[%out.print(hello());%]
World
[%
@template
operation hello(){%]
Hello

[%}%]


will produce

Hello

World


instead. Does this help?

Best,
Dimitris
Re: EGL undesirable trim on return template operations [message #1847930 is a reply to message #1847883] Sat, 13 November 2021 00:41 Go to previous message
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

Thanks, we will try that ASAP! @sam, can you please check if that works with

[% out.print(printAttributes(entity)); %]

If so, we need to document that for our purposes. It seems that the implicit stdout ([%=) perfoms a trim after return.
Previous Topic:Flock reordering items when using opposite references in EMF
Next Topic:Load HUTN as ecore model
Goto Forum:
  


Current Time: Sat Apr 27 11:04:05 GMT 2024

Powered by FUDForum. Page generated in 0.03883 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top