BlitzMax VSCode extension worklog

[Hezkore]

Since the modules are all documented now, it's possible to implement some neat features.
Like "jump to definition", which has a very nice "peek" mode.
It won't be very smart, like it won't detect methods and such correctly.
Eventually it might though, but not right now.
But I still find it very useful! Especially when the docs are lacking.

[Hezkore]

Features that were previously implemented had to be removed when I switched to my own documentation scanner.
And due to the missing features; I haven't released new extension versions in a while.
However most of the features (except for hover info) has been implemented again.
I've also implemented a new "signature help provider" which is basically just a fancy way of saying "function parameter hints".
Parameter hints were previously provided via hover information, or by the automatic snippets generated from the docs.
One problem though was that not everyone uses the snippets, so they'd have to hover over the function to see the parameters it took.

This is the old way (which still works just fine):


But you can now also get a real-time preview of what parameter you're editing:

_{(re-trigger parameter hints with Ctrl + Shift + Space in VSCode)}

[Hezkore]

I've finally implemented hover information again.
This time with working links.


Still working on showing the docs in a better way.
Right now I generate a .bmx document with the bbdoc, about and return information for the command.
But it looks very basic and boring, so I'm still trying to figure out how to use the VSCode webview to display things like that.

[Hezkore]

I've pushed an actual update to the extension on the Marketplace!
A big chunk of the extension has been redone and reworked to use node.js promises instead of only (yucky) callbacks.
What that means is that you should all be able to use the new features, like the signature help provider, RIGHT NOW!
But it also means that things will most likely be very broken for a while heh.
You'll likely see a lot of 1.7.x versions with small fixes.
And the code needs a lot of clean up, but I'll fix things as I go.
So please bare with me while we work on getting things up to speed together!

Oh and documentation viewing is now in, but very ugly and basic!
I'll work on that for sure, both on how it works, but also on how it looks.
Though, I've come to realize that it'll never be as pretty or fancy as BlitzMax's default docs.
But I think I'm okay with that.
It should eventually give you about the same information anyways.
And I find "peeking" at the definition WAY more informative than the docs anyways.
And I think I can get "peeking" working pretty well eventually.

I'm also planning on starting some of my own BlitzMax projects.
Which means I'll actually be using the extension!
Up until this point; the only BlitzMax related thing I've worked on is... well this extension.
So me actually using the extension should show me any problems or annoyances with it.

Feel free to give me a shout in this thread, or the official thread for the extension if you encounter any issues or have problems installing or setting things up.

Oh and we're almost at 100 installs, and over 150 downloads! 
Thanks to everyone for trying it out!

[Hezkore]

As expected; I've pushed a bunch of bug fixes, improvements and overall polish updates, all found by just using the extension myself.
We're up to to version 1.7.10 now, so 10 updates with several fixes in each.

One pretty embarrassing "bug" was that my cached modules would be included with the extension itself, whoops!
It was just the default modules, so things should be fine.
But if you have any problems related to the modules, such as hover info, peeking, caching/loading, auto-complete etc; what you can do is jump into your extension folder and remove 'modules.json'.
You'll find 'modules.json' at this location:
Windows: %USERPROFILE%\.vscode\extensions\hezkore.blitzmax*
macOS: ~/.vscode/extensions/hezkore.blitzmax*
Linux: ~/.vscode/extensions/hezkore.blitzmax*
I'll implement a command for rebuilding the docs in (hopefully) the next version of the extension, which means you won't have to manually delete the .json file.
And I'll stick a "version" tag in the .json, so that if I change how the modules are loaded; the extension will just update it for you.

[Hezkore]

Alright, version 1.17.12 is up!

1.17.12 features the new 'Generate Documentations' command.
Just hit Ctrl + Shift + P and type 'Generate' and it should show up.
This command will always generate documentations for all modules, no matter what time-stamp they might have.

And the 'modules.json' file is now replaced by a 'modules-<version>.json' file.
So when I update how the modules are generated internally; the old modules.json file won't be loaded anymore and a new one will be generated.
Which means that you should not have to worry about any of this anymore.
But if you somehow still have issues; just use 'Generate Documentations' and things should be fine.

[Hezkore]

More work on the extension!
A couple of fixes and changes that probably won't be so noticeable.
But the extension should work a lot better overall now.

One neat feature I'd like to mention is VSCode's "Remote" extensions.
If you're on Windows 10 and using the Windows Subsystem for Linux; you can use the 'Remote - WSL' extension.
You'll instantly jump into Linux and compile your BlitzMax code there!
It also works (almost exactly the same) over SSH by using the 'Remote - SSH' extension.
So if you have a Linux machine somewhere; you can use it to compile your code.

Here's a short clip of me on Windows 10 using SSH to compile some BlitzMax code on my server computer running terminal Debian:

[Hezkore]

There was recently a new VSCode update which added support for "task resolving", which is something I've wanted for a long time.
Basically what it means is that I can now let the user modify `tasks.json` and have the extension properly read the modified data.
So I rewrote the build/task system for the 1.8.0 update to support the new features, and I'm pretty happy with the result.
And it should now be a lot less confusing to build and configure your applications.

Basically you just hit F5 or Ctrl + Shift + B to build.
F5 will always execute the newly built application.
While Ctrl + Shift + B will be a "proper" build, something you do when you're making a release.

You'll get to select the kind of application you want to build and a `tasks.json` will be created for you.
You can edit this file yourself and configure your application any way you want.



You can also have multiple build tasks configured.
If you're building a server and a client; you could have two tasks, one for the client and one for the server.
And you could have a third task that builds AND executes both the server and client.

Give me a shout if you want any other build options implemented.


Oh and we've passed 100 installs and over 250 downloads.
That means that over half of the SyntaxBomb forum is using the extension.
Now... I'm 100% sure these numbers are incorrect, but hey, you've got to celebrate something, right? ¯\_(ツ)_/¯

Thanks everyone.

[iWasAdam]

all looks very slick

question.
is it available for macos?

[Qube]

all looks very slick

question.
is it available for macos?

Agree with all that - Really great work.

[Derron]

Yes it looks nice - still awaiting/wishing for  a proper intellisense thing (so scanning your imported files rather than just modules and also knowing the type of the current variable to provide methods/functions/...). Think this is a pretty complex task (you need to create a grammar and so on so that VStudio knows how to tackle stuff).

Keep up with that project as long as you are motivated enough to do that.


bye
Ron

[Hezkore]

Thanks everyone.

@iWasAdam
Yeah both VSCode and the extension is available for macOS.
You can find out more at the release thread: https://www.syntaxbomb.com/index.php/topic,5771.0.html
I haven't actually tested it on macOS (not used my Mac in a long time...), but I am following all the rules with the extension heh.

@Derron
Yeah that is the dream!
Sadly there's no way of just telling VSCode how the language works and have it to do the work.
I'd have to manually parse all the BMX code (imports, modules etc.) and build some sort of tree structure myself.
Then when the user writes something I'd have to check what they're writing and reference the tree.
There's no automatic process for it sadly.

Another thing I'm hoping I can add in the future is proper debugging.
But the debugging example is so over engineered and specific that I'm not even able to modify it to use the BMK compiler.
But we'll see what happens.

[Derron]

https://en.wikipedia.org/wiki/Language_Server_Protocol

This is what Studio supports. So in essence you would write a piece of code which returns all the required information of your source to Studio (or other Editors supporting LSP). Brucey once wrote he played a bit with it but for now there is no repository to sneak peak ;-)

So instead of writing something specific to Studio it would be better to support that whole thing in a way that allows to use it even with other editors.


bye
Ron

[Hezkore]

For sure!
It'd be awesome if Brucey finally finished it.

[Hezkore]

Lately I've been working on a network module that comes with a server and client.
However modules need to be inside the BlitzMax 'mod' folder, but I instead wanted to work from my normal projects folder that contains all of my BlitzMax code.
Thankfully VSCode has some pretty nice dependency management for tasks!

Just by pressing F6 (Run previous task) in VSCode; the module will be moved over to my BlitzMax 'mod' folder.
When the move is complete; both the server and client -- which uses the module -- will be built simultaneously inside my normal project folder.
And when the build process is complete; both the client and server will be started simultaneously, nicely displayed next to each other.

This is achieved by having some compound tasks in the 'tasks.json'.
You can read more about them here: https://code.visualstudio.com/docs/editor/tasks#_compound-tasks

But basically what you do is setup a normal 'bmx' build task for the server and then another build task for the client.
Then you can do something like this to build both at the same time:

Code: [Select]

{
"label": "Build Server & Client",
"dependsOrder": "parallel",
"dependsOn": [
"Build Client",
"Build Server"
],
"group": "build"
}Notice "dependsOrder": "parallel", this can also be "sequence"

And to move the module over to the 'mod' folder; you can just run a normal 'shell' task and something like 'robocopy' to only copy the newer files:

Code: [Select]

{
"label": "Update Module",
"type": "shell",
"command": "",
"windows": {
"command": "robocopy",
"args": [
"/e",
"/xo",
"${workspaceFolder}\\src",
"${config:blitzmax.bmxPath}\\mod\\hez.mod\\znet.mod"
]
},
"group": "build"
}Notice '${config:blitzmax.bmxPath}' which always points to your BlitzMax folder

Now I can easily test the module, server and client at the same time, just by pressing F6: