Eclipse Community Forums: TMF (Xtext) » Debugging a DSL with spaces in its path

Home » Modeling » TMF (Xtext) » Debugging a DSL with spaces in its path(Xtext cannot find DSL source when breakpoint hit if its path has a space)

Show: Today's Messages :: Show Polls :: Message Navigator

Debugging a DSL with spaces in its path [message #1820722]

Mon, 27 January 2020 17:23

Steve Pearson

Messages: 12
Registered: May 2014

Junior Member

We have an Xtext DSL and code generator using the Tracing Code Generator as described in this blog:https://blogs.itemis.com/en/debugging-dsls-in-xtext-and-eclipse.
This normally works very well. The generated code together with a ._trace file is written to the src-gen folder by default and when executed will stop and display breakpoints in the DSL.
However, if there is a space in the workspace path then the DSL is not found when the breakpoint is hit.. The DSL source is not displayed and debugging is impossible. Could this be something to do with Xtext's interpretation of its ._trace file? Although binary the path name can be seen encoded as XML with %20 replacing any spaces. Could it be related to the EMF Resource URI encoding? The attached screenshot shows what happens.
index.php/fa/37236/0/

Attachment: XtextTraceWithPathSpace.JPG
(Size: 31.42KB, Downloaded 258 times)

Report message to a moderator

Re: Debugging a DSL with spaces in its path [message #1820725 is a reply to message #1820722]

Mon, 27 January 2020 18:57

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

did you debug the source lookup? / installation of debug information into the class files / setting of breakpoints?

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

[Updated on: Mon, 27 January 2020 19:00]

Report message to a moderator

Re: Debugging a DSL with spaces in its path [message #1820749 is a reply to message #1820725]

Tue, 28 January 2020 11:10

Steve Pearson

Messages: 12
Registered: May 2014

Junior Member

Xtext generates the traceRegion for this example in org.eclipse.xtext.builder.updateTraceInformation:
line 423: AbstractTraceRegion traceRegion = ((ITraceRegionProvider) contents).getTraceRegion()

CompletableTraceRegion [myOffset=0, myLength=4385, useForDebugging=false] associations={
  LocationData [TextRegionWithLineInformation [0:51][lineNumber=0, endLineNumber=4]][path=aa%20bb/test2.proc]
} nestedRegions={
  CompletableTraceRegion [myOffset=3631, myLength=215, useForDebugging=true] associations={
    LocationData [TextRegionWithLineInformation [21:27][lineNumber=1, endLineNumber=3]][path=aa%20bb/test2.proc]
  } nestedRegions={
    CompletableTraceRegion [myOffset=3704, myLength=39, useForDebugging=true] associations={
      LocationData [TextRegionWithLineInformation [33:11][lineNumber=2, endLineNumber=2]][path=aa%20bb/test2.proc]
    }
  }
}

There is a '%20' in the relative path to the DSL instead of a space: [path=aa%20bb/test2.proc].

This comes from a call to the DefaultTraceURIConverter org.eclipse.xtext.generator.trace.getURIForTrace which returns aa%20bb/test2.proc.

I overrode this method and the problem went away. So we have a workaround (albeit with Discouraged access).

In my version of org.eclipse.xtext.generator.trace.DefaultTraceURIConverter::getURIForTrace(IProjectConfig projectConfig, AbsoluteURI absoluteURI).

I pre-process your absoluteURI using EMF's URI.decode

      AbsoluteURI decodedAbsoluteURI = new AbsoluteURI(URI.createURI(URI.decode(absoluteURI.getURI().toString())))

Is this a bug or is there a configuration I have missed?

Report message to a moderator

Re: Debugging a DSL with spaces in its path [message #1820752 is a reply to message #1820749]

Tue, 28 January 2020 11:31

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

i think nobody seems to have thought about this usecase.
can you create an issue at github.com/eclipse/xtext-core.
so that we can discuss if its a bug or a feature there
if you know a general fix you could also come up with a PR
as we dont have the capacity to work on too many things currently

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Debugging a DSL with spaces in its path [message #1820753 is a reply to message #1820752]

Tue, 28 January 2020 11:32

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

i also dont know if the JSR45 says anything about the the source files should be encoded. so it might be a bug in jdt too.

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Debugging a DSL with spaces in its path [message #1820760 is a reply to message #1820753]

Tue, 28 January 2020 12:57

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

for completeness
https://github.com/eclipse/xtext-core/issues/1371

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Debugging a DSL with spaces in its path [message #1820771 is a reply to message #1820760]

Tue, 28 January 2020 14:18

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Most code where awkward characters can be troublesome have evolved a very diligent API that enables the use of raw/safe representations to be accommodated.

For EMF, whenever you create a URI from a String, you must provide a Boolean argument that says whether conversion to a safe representation has already occurred and should not be repeated. Conversely whenever you convert a URI to a String you must specify whether you want the raw or safe representation.

Most programmers neglect to pay as much attention as they could when specifying these arguments, and for sensible file names, who cares, it is not a problem; "true" will do.

However if you insist on using awkward names you can expect that almost every tool that you use will have multiple representation preservation bugs and you can spend your time complaining to the developers. This one looks like an Xtext oversight.

Much simpler to avoid the problems. I install everything that I care about in C:\Tools not C:\Program%20Files.

(With hindsight, EMF could have distinct RawURI and SafeURI classes so that the type system rather than the programmer's diligence ensures appropriate conversions.)

Regards

Ed Willink

Report message to a moderator

Previous Topic:	The filename or extension is too long
Next Topic:	Recommended terminal value for auto-completion

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 03:31:22 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter