Gideros VSCode integration

antix · January 2021

I've made some VSCode extensions to enable the use of VSCode as a Gideros IDE. All of the extensions can be found in the Extensions Marketplace by searching for "Gideros". Maybe other Giderians will find it useful, maybe not.

Gideros - A VSCode version of EmmyLua with integrated Gideros framework support. Framework support is implemented in the form of code completion and vanilla Lua syntax checking. At this time, syntax checking does not include support for Gideros Lua Enhancements.

Gideros Debug - A modified version of the VSCodeLuaDebug extension by devCAT.

Plastic Lua Wrap - A VSCode color theme for the Lua programming language, in the style of Plastic Code Wrap. This is not required, I just like this theme so much I had to recreate it for Lua!

The integration is in it's infancy and whilst it works (for me at least) there are some things that do not behave as expected:

Platform Support - The debugger is for Windows only so no Mac debugging will be possible without somebody with a Mac and the skills can recreate the debugger for that platform. Optionally post me a Mac and I'll see what I can do.

Code Completion - Some documentation might seem to be incorrect. This is basically because the Gideros Wiki is a bit of a mess.

Code Completion - Some documentation missing entirely. Once @hgy29 has modified his export script this should be resolved.

Syntax Errors - I haven't yet been able to figure out how to get the language server to accomodate for the extra operators that Gideros has, such as "+=" and so on. Whilst these are displayed inside VSCode as errors, your applications will still run.

Debugging - I have quickly modified the "debugee.lua" file to work with Gideros but have not tested it. I personally do not use this as I'm only interested in printing stuff to VSCodes Debug Console. If it's not working for you, let me know and I'm happy to try and help

Project Management - You still need to use Gideros Studio to manage your actual project, and of course export. I am currently thinking about adding another extension for project management.

Anyway... This rudimentary integration now allows me to use VSCode as my IDE for my Gideros projects, and I've immediately begun to code faster because of the incredible editing features that VSCode provides.

rrraptor · January 2021

Is there a way to change "giderosPath" default value?

antix said:
Gideros - A VSCode version of EmmyLua with integrated Gideros framework support.

For whatever reason it does not work for me.

keszegh · January 2021

hi, i get a missing java error: "Can't find Java! Please install Java 1.8 or above and set JAVA_HOME environment variable."
i have android studio installed and so i did not need java and it's always a mess so i'd rather not install it. can i use your extension without java installed? (i tihnk a java jre is inside android studio folder however)

keszegh · January 2021

also, does it have any kind of outline view (showing the list of functions of the opened file)? that's pretty handy in zbs and gideros studio.

rrraptor · January 2021

keszegh said:
also, does it have any kind of outline view (showing the list of functions of the opened file)? that's pretty handy in zbs and gideros studio.

keszegh · January 2021

thanks @rrraptor , i have to sort out that java issue and then the outline shall show up there, cool.

keszegh · January 2021

the git integration is handy, i have to admit.

antix · January 2021

@rraptor Okay trying to recreate the scenario you presented using your screenshot is nigh on impossible. Would you be so kind as to paste the source as text so I can input it on my system to reproduce the error?

Currently the debug extension has no setting to change the default Gideros install path but you can probably set it by manually changing the "package.json" file in the extensions folder, which will be something like... %userdata%\.vscode\extensions\antixdevelopment.gideros-debug-1.0.1. Once changed there it should create the desired path for each new launch.json file you create. I can try to add a dedicated setting for that.

@keszegh If you go to Start > Control Panel > System > Advanced System Properties > Environment Variables... do you have a JAVA_HOME listed, and does it indeed point to a valid JRE installation folder?

After removing the JAVA_HOME environment variable the extension indeed no longer works.

If you want to use the JRE that comes with Android Studio, then you will need to set the JAVA_HOME environment variable to the JRE path of your Android Studio installation. For me it is... C:\Program Files\Android\Android Studio\jre, as shown below...

Doing this made the extension work again.

I also find GIT integration really fantastic

keszegh · January 2021

thanks, JAVA_HOME setting to android studio jre helped. now outline works. yet when i click on run it does nothing (i select gideros player and then nothing happens).
also is there a way to show only functions in the outline or at least to put them forward? i do not want to see all the local variables.

keszegh · January 2021

ok, i've changed the path to gideros in the launch.json, now it starts to run but then i get an error similar to what @rrraptor shared.

keszegh · January 2021

like this.

keszegh · January 2021

changing the appropriate line in launch.json to
"gprojPath": "${workspaceRoot}/${workspaceFolderBasename}.gproj",
made it run. btw workspaceRoot is depracated and workspaceFolder should be used according to some forum.

keszegh · January 2021

projects with "<>" etc do not run for me though.

rrraptor · January 2021

antix said:
@rraptor Okay trying to recreate the scenario you presented using your screenshot is nigh on impossible. Would you be so kind as to paste the source as text so I can input it on my system to reproduce the error?

What text do you need? "launch.json" or what?

Project path: "E:\GameDev 2.0\Gideros\LightsUP"

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: <a href="https://go.microsoft.com/fwlink/?linkid=830387" rel="nofollow">https://go.microsoft.com/fwlink/?linkid=830387</a>
    "version": "0.2.0",
    "configurations": [
        {
            "name": "launch-gideros",
            "type": "lua",
            "request": "launch",
            "workingDirectory": "${workspaceRoot}",
            "giderosPath": "E:/Soft/Code/Gideros",
            "gprojPath": "${workspaceRoot}/LightsUP.gproj",
            "jumpToGiderosErrorPosition": false,
            "stopGiderosWhenDebuggerStops": true,
            "listenPublicly": false,
            "listenPort": 56789,
            "encoding": "UTF-8"
        },
        {
            "name": "wait",
            "type": "lua",
            "request": "attach",
            "workingDirectory": "${workspaceRoot}",
            "sourceBasePath": "${workspaceRoot}",
            "listenPublicly": false,
            "listenPort": 56789,
            "encoding": "UTF-8"
        }
    ]
}

hgy29 · January 2021

Good job @antix! I am getting a few issues too, though and I'd like to debug/improve it myself. How should I proceed to dive in the extension code ?

rrraptor · January 2021

I tried everything from here:
https://stackoverflow.com/questions/8821410/why-is-access-to-the-path-denied
and some other methods. But nothing works.

keszegh · January 2021

i also got the access denied to the folder error.

antix · January 2021

@keszegh Using the VSCode variable like that to load the gproj file is very cool, and I've noted that workspaceroot is indeed depreciated. I'll update everything accordingly

@rrraptor If you could paste that code into a reply that would be good

The access denied thing is in the debugger code (eeeek). I'll start looking into that using the sackexchange thread @rrraptor posted.

I'll also install everything onto a machine that is basically a fresh Windows 10 install and see if I can replicate the issue.

Can I safely assume that the only real issue right now is the access denied issue? And, that issue applies to any Gideros project you try to use?

@hgy29 Hmm, I can give you access to the master if you like.

keszegh · January 2021

actually i have a project which runs fine but i don't see the reason.

keszegh · January 2021

btw i've managed to hide variables in the outline view through settings, see also https://stackoverflow.com/questions/56247710/is-there-a-setting-to-filter-out-variables-from-breadcrumbs-in-vscode

keszegh · January 2021

@antix, for me it's also an issue that custom lua extensions like <> stop the project from trying to run.

keszegh · January 2021

it's strange in vscode that one cannot have sidebar both on the left and right.

antix · January 2021

@keszegh Okay I've got it installed on my test machine and I've also got the access denied error. I can now begin fixing it

On my main machine where everything magically works I can use "<>" and it's all fine, even though the editor shows a syntax error. This is because EmmyLua (which the extension is based on) does not know how to process these extra Gideros operators. I'm looking at the luaparse node library and think that might be the place to change things, or it might require looking at the actual Java code for the extension (eeek)

antix · January 2021

@keszegh Ahh nice find on the "variables in outline" thing. Last time I looked for such a solution it didn't exist

With regards to the access denied issue, I've discovered the problem, and it's to do with when Gideros was changed to have the "assets" folder thing.

In the old style of resource management inside a gproj file there would be entries like...

 <file source="main.lua"/>

But in the new style there are entries like...

 <file name="assets/main.lua"/>

The extension is loading files based on the source= syntax, not the name= syntax. This is because it was created at a time before the new syntax, has not been updated to the new syntax, and the entire project seems to have been abandonned by the author.

~~@hgy29 Is there any particular reason the new style doesn't use the source= syntax? It seems to me that it would be good to have consistency there.~~

The attached zip contains two projects, test, and test2. test will crash as it uses the new file syntax and test2 works fine because it uses the older syntax.

The reason I've never had the access denied issue is because I'm a caveman and never switched to the new style of project management

EDIT: I'm now looking at the debugger c# code and I can see that there actually is code to manage both syntaxes. Dammit! I wonder WTF is happening there

keszegh · January 2021

indeed the project which runs has no extended lua code and has 'file source'. while the ones which have issues have either extended lua code (and thus not run) or 'file name' (and gives error).

antix · January 2021

Okay I discovered the whole access denied issue was due to a typo in the original extension. It's fixed now

https://github.com/Antix-Development/VSCode-Gideros-Debug/issues/1

I've also modified the default launch.json configuration so you don't need to manually set the gproj name...

https://github.com/Antix-Development/VSCode-Gideros-Debug/issues/2

I just packaged and published 1.02 so it should be auto updating very soon.

Thanks heaps guys for finding bugs and offering improvements!

keszegh · January 2021

thanks.
yet in 1.02 i still get the access denied issue.

antix · January 2021

~~@keszegh what the... have you a small project that you can attach that still has the issue? Maybe even just the .gproj file would suffice.~~

It is also possible that I didn't update the DLL in the updated version. I'll check that...

Yes.. I forgot to put the DLL in the right place... what a moron I am sometimes heheh. Apologies, I should have tested it on my other machine before posting 1.02. 1.03 is available now and seems to work

keszegh · January 2021

that helped.
yet more complicated projects do not run. i pm you one to test if you like.

antix · January 2021

@keszegh Okay got it. I'll have a look

Very strange. In both Gideros Studio and Zerobrane Studio, the file API.lua is accepted. When launching from VSCode there's an error API.lua:8: '+=','-=','*=', '/=', '%=', '^=', '=' expected near 'ImGui'

If I set the API.lua file to not be executed then Gideros Player starts, and then immediately ends. I couldn;t find any log file for Gideros Player so looked in Windows Event Viewer. In the Application section I found a .net error with the following details...

Application: DebugAdapter.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Exception
   at GiderosPlayerRemote.GiderosMessageReader.ReceiveMore()
   at GiderosPlayerRemote.RemoteController.ReadLoop()
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Threading.ThreadHelper.ThreadStart()

I'll begin trying to decipher just WTF that all means.

There is also another error in the log...

Faulting application name: GiderosPlayer.exe, version: 0.0.0.0, time stamp: 0x5fbbcd71
Faulting module name: imgui.dll, version: 0.0.0.0, time stamp: 0x5fbbcccf
Exception code: 0x40000015
Fault offset: 0x0008e4bc
Faulting process id: 0x217c
Faulting application start time: 0x01d6e3bf25813d24
Faulting application path: C:\Gideros\GiderosPlayer.exe
Faulting module path: C:\Gideros\Plugins\imgui.dll
Report Id: ef4cc8a3-5cdc-44a5-84b4-3abb03a22fa5
Faulting package full name: 
Faulting package-relative application ID:

antix · January 2021

@keszegh I got your PM and looked at your project...
Once I excluded API.lua, other.lua, and temp.lua from execution... it runs for me.

I see in those files there is some text at the top --!NOEXEC, and after looking at the wiki I see that this (and others) were added to Gideros some time ago.

Unfortunately the extension the Gideros debugger is based on does not support this method of excluding files from execution.

Personally I'm happy to use the old way of excluding files from execution inside Gideros Studios built-in project management, but if you really think it's something that you need then please open an issue on the extensions repo and I'll look into it.

I've added !NOEXEC support to Gideros Debug and published it in 1.0.6 which is now available as an update.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Gideros VSCode integration

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Gideros VSCode integration

Comments