[BUG] Using "echo" in project.xml causes builds to fail in Run and Debug.

[EliteMasterEric]

I've only been able to reproduce this on Windows, but I can reproduce it reliably with the following steps.

1. Run lime create SimpleImage to create a simple project.
2. Open the project in VSCode. Go to the Run and Debug tab, create a simple Lime launch option, and test that the program builds and launches.
3. Navigate to project.xml and add the following line. Here we're using an example string, but in a real application, this could be tied to a condition or be inside a <section> block.

   <echo value="Hello, world!" />

4. Attempt to build and run the project again.

The project will build, but VSCode will not launch the program, as it will indicate a build failure:

This is logical for the <error> tag but not for the <echo> tag, which is used to provide informational messages to the user and does not indicate a build failure.

[EliteMasterEric]

This issue also seems to occur when compiling a program which includes a macro that calls Context.info(), which is supposed to be used to print debug information at compile time but is instead displayed as an error in the Problems tab.

[player-03]

Go to the Run and Debug tab, create a simple Lime launch option,

Is this necessary? As described here, the extension should detect your project and create a "run test" command.

[EliteMasterEric]

@player-03 The simple Lime launch option I mention is automatically added to your project configuration when you press F5 and select "Lime" as the environment.

[player-03]

Oh I see, you're trying to set up a debugger. Yeah, my method just calls lime test <target> in the terminal and lets it run. Presumably that'll still work, if you're fine giving up the debugging features.

While I don't know much about using debuggers in VS Code, a little more info might help:

• What target are you building for, in this example?
• Do you have that target's debugger extension installed?
• Can you post the generated launch.json file?
• When testing an HXP project, is there any difference between trace(), Sys.println(), Sys.stdout().writeString(), and Sys.stderr().writeString()?

[EliteMasterEric]

I should have mentioned it in the issue, but yes, lime test windows works as expected.

I get this issue when building for the Windows target, and if I recall this bug does not occur on my Linux machine (will have to test it out).

I will test with HXP and get back to you.

[EliteMasterEric]

@player-03 Just wanted to let you know this bug is still an issue for me. Testing the HXP project, I found no difference in behavior between those methods you listed.

The workaround I've been using is to simply replace all my log calls with a local function, then comment out the actual Log.info call when I want to use VSCode. This sucks since I lose all the helpful print calls I was using, but it works.

[player-03]

So wait, are you trying to use a debugger? You haven't confirmed or denied. If not, I want to reiterate that there's a much easier way.

1. Open up your keyboard shortcuts.
2. Search for "Run Test Task".
3. Add a shortcut.

Whenever you press this hotkey, it'll bring up a list of options, and you want to choose "lime: test". Everything will just work from there.

[EliteMasterEric]

Okay, to clarify, my workflow is:

1. Use the following contents for .vscode/launch.json.

   {
   "version": "0.2.0",
   "configurations": [
       {
           "name": "Build and Launch",
           "type": "lime",
           "request": "launch"
       }
   ]
   }

2. Use the dropdown at the bottom to select the platform (usually Windows / Debug).
3. Press F5 or the Run button. This will build the application; if build fails, it will report the issue in the Problems tab.
4. If it succeeds, it will launch the application with debugging enabled (for Windows I'm using the HXCPP Debugger). This allows VSCode to automatically bring up the relevant file when an exception occurs, and enable support for breakpoints. These latter two are an important part of my workflow.
5. Shut down the app, make changes, then press F5 to build again.

I just did some more testing; the built application launches just fine with this method, with either HXP or XML. However, the app only launches when logging statements are commented out. If any logging statements are present, the app simply... doesn't start.

Maybe the issue is with the extension?

[player-03]

for Windows I'm using the HXCPP Debugger

Got it. Afraid I don't have any experience with the debugger, or the Lime extension for that matter.

Correction: I didn't, and then I started collecting info to get you started. That's how it goes sometimes. I might even have found the answer, but first let's go over everything else for context.

• By default, type can only be "node" because that's what's built in. You have to get an extension to enable other values.
• The Lime extension registers itself here, enabling "lime" as an option. There's also some documentation for the registerDebugConfigurationProvider() function as well as the DebugConfigurationProvider type.
• resolveDebugConfiguration() adds some attributes to the configuration, notably preLaunchTask. But if a preLaunchTask already exists, it'll leave it alone, so you could see if a custom task produced the same issues. Since you've already compiled at least once, this custom task could be as simple as echo "hello world".
• Tasks can - and often do - come with problem matchers. You could make your own, to see if you can turn echo "hello world" into an error.

So what problem matchers come with the Lime extension? Apparently the ones from the Haxe extension. Let's look those up...

final problemMatchers = ["$haxe-absolute", "$haxe", "$haxe-error", "$haxe-trace"];

Well. Would you look at that. There's a problem matcher named haxe-trace. While it does set "severity": "info", I wonder if that's the problem?

OTOH, you said it assumed Sys.stdout().writeString() was an error, so who knows? Anyway, hopefully this gives you more things to test.

[EliteMasterEric]

@player-03 I thought that would be the solution the issue, but it seems that, even when I define an empty patternMatcher, the same behavior occurs. The project launches, complete with a properly attached debugging, but only when any logging is disabled.

It's still building, and using my selected build configuration, and no problems appear in the Problems tab anymore (as long as the patternMatcher) is empty, but the app doesn't start.

It's not my workspace either; I tested the problem in my DisplayingABitmap workspace too and was reliably able to reproduce the problem on both XML and HXP.

[player-03]

Yeah, I have no idea. Until someone comes along who knows more about this, I'd suggest writing to a text file as a workaround. Then open it using <postbuild open="log.txt" /> or postBuildCallbacks.push(CommandHelper.openFile("log.txt")).

[EliteMasterEric]

I'd suggest writing to a text file as a workaround. Then open it using <postbuild open="log.txt" /> or postBuildCallbacks.push(CommandHelper.openFile("log.txt")).

This seems to be a good compromise. With this solution I did find that the postBuildCallback call doesn't do anything, but that doesn't matter since I'm getting the middle ground between being able to view the log output of my HXP project (by opening the file) while also being able to debug in VSCode.

[player-03]

the postBuildCallback call doesn't do anything

Odd. That just uses the start command on Windows, which ought to work. Maybe try an alternate command (postBuildCallbacks.push(new CLICommand("code", ["log.txt"]))), and/or specifying the absolute file path.

Or just keep the file open in a tab.

[EliteMasterEric]

I just tried to switch a newer project to HXP and encountered this issue again. Any info on this? I'd really like to keep logging in place if possible.

[joshtynjala]

if I recall this bug does not occur on my Linux machine (will have to test it out).

I also just tested on macOS, and adding an <echo/> element doesn't break my ability to build and debug. However, it does cause the language server to incorrectly detect the echo value as a classpath.

<echo value="hi"/>

Package "hi" was not found in any of class paths

I had to add an if="!display" to fix that (and this might help you too, @EliteMasterEric).

<echo value="hi" if="!display"/>

I think that we should update Lime to automatically skip the <echo/> element for the "display" command, which is used to configure VSCode projects. We skip a lot of things for the "display" command already, for the same reason.