Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
Gideros VSCode integration - Gideros Forum

Gideros VSCode integration

antixantix Member
edited January 9 in User experience
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.
+1 -1 (+4 / -0 ) Share on Facebook
«1

Comments

  • rrraptorrrraptor Member
    edited January 5
    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.



    access_denied.jpg
    392 x 419 - 140K
    image.png
    992 x 619 - 64K
  • 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)
  • 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 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.


    GidOuline.png
    1234 x 1014 - 145K
  • thanks @rrraptor , i have to sort out that java issue and then the outline shall show up there, cool.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • the git integration is handy, i have to admit.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    edited January 5
    @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 :)
    JAVA_HOME.png
    632 x 592 - 30K
  • 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.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • 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.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • like this.

    Likes: antix

    Screenshot 2021-01-05 13.23.21.png
    427 x 660 - 32K
    +1 -1 (+1 / -0 ) Share on Facebook
  • 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.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • projects with "<>" etc do not run for me though.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • rrraptorrrraptor Member
    edited January 5
    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" target="_blank" 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"
            }
        ]
    }

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • hgy29hgy29 Maintainer
    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 ?

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • i also got the access denied to the folder error.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    @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.
  • actually i have a project which runs fine but i don't see the reason.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • @antix, for me it's also an issue that custom lua extensions like <> stop the project from trying to run.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • it's strange in vscode that one cannot have sidebar both on the left and right.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    @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)
  • antixantix Member
    edited January 5
    @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 :D

    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 :neutral:
    zip
    zip
    testcrash-test2nocrash.zip
    4K
  • 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).
  • antixantix Member
    edited January 5
    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!

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • thanks.
    yet in 1.02 i still get the access denied issue.

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    edited January 5
    @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 ;)

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • that helped.
    yet more complicated projects do not run. i pm you one to test if you like.

    Likes: MoKaLux

    +1 -1 (+1 / -0 ) Share on Facebook
  • antixantix Member
    edited January 6
    @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:
  • antixantix Member
    edited January 6
    @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.

    Likes: MoKaLux, keszegh

    +1 -1 (+2 / -0 ) Share on Facebook
Sign In or Register to comment.