- improvements to typechecking - it now respects order in which symbols are declared (only in scope of single file). That means if you'll try to reference variable/function declared X lines below it will print an error msg.
Natives not declared in Galaxy files will now be auto-generated every release. There were quite a lot of them actually:
That's because you were previously accepting "AIEvalSetCustomIndex" as suggestion, when typing "else". For that reason, editor now assumes it is your preference over keyword "else", which previously was not available - look that "else" is now at the top of the list. As far as sorting goes it is fine. You probably just have to choose "else" once, and editor will remember your choice. It's actually recent feature of VSCode https://code.visualstudio.com/updates/v1_19#_smarter-intellisense
And do not check if return is exist.
Added to the list.
I'll probably slow down with work on new features in upcoming days/weeks, and switch my focus to other stuff. But keep reporting any issues you encounter - these are useful, as I don't work much with SC2 projects recently.
However, as a long term plans.. or rather ideas. I'd like to implement frontend debugging UI for Galaxy in VSCode ( https://code.visualstudio.com/Docs/editor/debugging ). Which would utilize default TrigDebug window as a starting point. Primary reason is to make new frontend convenient to use, because default one is not so friendly... perhaps it would be possible to come up with some exclusive features. Although SC2 binaries got really hard to RE during these years (and I never was good at that to begin with :| ). I gotta dig more to see whether something like this would be feasiable at all.
The other thing I'm considering is yet another Galaxy Language Extension - acting as transpiler. My focus on this would be on features meant to improve usability, while avoiding implementing dynamic capabilities like Galaxy++ did. As there's no easy way to emulate that - it quickly gets messy. But seeing how low interest there's about Galaxy related things within community, it might be simply too late for such project. If I'm however wrong about that, I'm open for collaboration.
That's because you were previously accepting "AIEvalSetCustomIndex" as suggestion, when typing "else". For that reason, editor now assumes it is your preference over keyword "else", which previously was not available - look that "else" is now at the top of the list. As far as sorting goes it is fine. You probably just have to choose "else" once, and editor will remember your choice. It's actually recent feature of VSCode
I have not use vscode before.
I'll probably slow down with work on new features in upcoming days/weeks, and switch my focus to other stuff. But keep reporting any issues you encounter - these are useful, as I don't work much with SC2 projects recently.
Now this is the best one for writing galaxy. Thanks for your work again.
However, as a long term plans.. or rather ideas. I'd like to implement frontend debugging UI for Galaxy in VSCode ( https://code.visualstudio.com/Docs/editor/debugging ). Which would utilize default TrigDebug window as a starting point. Primary reason is to make new frontend convenient to use, because default one is not so friendly... perhaps it would be possible to come up with some exclusive features. Although SC2 binaries got really hard to RE during these years (and I never was good at that to begin with :| ). I gotta dig more to see whether something like this would be feasiable at all.
You mean use vscode to debug Galaxy script? You want to write a VM for galaxy or run SCII and get data and control the game? BLZ start to add features for SE, so it will be a continuous work. If you finish it, it will be great! As we know, BLZ have never supported a good debug tool, no matter WE of War3 and SE of SC2.
The other thing I'm considering is yet another Galaxy Language Extension - acting as transpiler. My focus on this would be on features meant to improve usability, while avoiding implementing dynamic capabilities like Galaxy++ did. As there's no easy way to emulate that - it quickly gets messy. But seeing how low interest there's about Galaxy related things within community, it might be simply too late for such project. If I'm however wrong about that, I'm open for collaboration.
I am a original-edition-ism user. It is a bad habit of caring efficiency from the period of War3. I do not like vJass, cJass and other extensions of Jass2, the script language of War3. But for SC2, galaxy is enough efficient. So I have never used the extension of Galaxy++.
It is just a habit. And I think you can add a support of write a class, which can add methods to a struct (just like a class in c++),as a further feature support the scope of methods and field of struct.
As you say, it may be so late to do this. I think I will not a user of it, but I think it is worthwhile. For War3 in China there are still so much mapmakers woke for WE tools, before the Class Team of BLZ continue its work of War3 in years. The fist thing is if you want and have enough time to do, is not if it so late. Is that right?
You mean use vscode to debug Galaxy script? You want to write a VM for galaxy or run SCII and get data and control the game? BLZ start to add features for SE, so it will be a continuous work. If you finish it, it will be great! As we know, BLZ have never supported a good debug tool, no matter WE of War3 and SE of SC2.
Yes, plan is to use SC2 VM. Since SC2 already has debugger to control VM, I can utilize it by just hooking up relevant winapi controls.
Of course I'd like to go a little beyond that - inject some additional binary code to SC2.exe that would allow to for example modify values of variables. But that requires further research..
I am a original-edition-ism user. It is a bad habit of caring efficiency from the period of War3. I do not like vJass, cJass and other extensions of Jass2, the script language of War3. But for SC2, galaxy is enough efficient. So I have never used the extension of Galaxy++.
Yes, I wouldn't like to implement features that would noticeably impact performance.
I was thinking about features such as:
- modularity/namespaces: Galaxy has single global module and everything is put into the same namping space - included files can access everything what was declared by parent files..
- Tigger Library generation from Galaxy code
- some syntatic sugar for things like passing variables as references (Galaxy requires you to wrap it with arrayref), iterator interfaces to provide foreach loops
- maybe some C like preprocessing macros..?
etc.
I really think there's a lot that can be done to make Galaxy "more friendly" - reduce the amount of boilerplate code it often requires to accomplish simple things.
Well, we'll see if I'll be motivated enough to put needed time into this.
Because we all talk here, so I report bugs here, GitHub is ok too, it may be more quick for me to visit.
For the if bug, I have tested in SE, if "if (true)" is in another line, it did not pass the syntax checking. But now it pass... Maybe BLZ fix it? !!!∑(゚Д゚ノ)ノ
I will report in GitHub if find another bug, hope I won't have a chance to do.
In general whitespaces are ignored in languages where they are not used for indicating beginning and start of the block (such as Python etc.). Galaxy mostly follow C syntax, thus you could even do things like:
int lv_I;
if (true)
{
lv_I+= 1;
}
else
// a
if
(
true
)
{
lv_I
+=
1;
}
And it should work (it does in current version of SC2). But you might be right - I never tested how it did behave in the past.
Reporting bugs here is completely fine too. But I just respond to it slower, since I don't visit the site so often anymore.
Released v1.7.0 (rough changelog)
Most notable changes are probably:
- find all references [1] & symbol rename
- improvements to typechecking - it now respects order in which symbols are declared (only in scope of single file). That means if you'll try to reference variable/function declared X lines below it will print an error msg.
Natives not declared in Galaxy files will now be auto-generated every release. There were quite a lot of them actually:
https://github.com/Talv/sc2-data-trigger/blob/e9507ff419107981e5b98cf0eec70c2e17147db6/mods/core.sc2mod/base.sc2data/TriggerLibs/natives_missing.galaxy
[1]
Previously known as: SomeoneTookMyNameTT
Keyword "else" is add, but not the auto-select one when I input "else".
And do not check if return is exist.
That's because you were previously accepting "AIEvalSetCustomIndex" as suggestion, when typing "else". For that reason, editor now assumes it is your preference over keyword "else", which previously was not available - look that "else" is now at the top of the list. As far as sorting goes it is fine. You probably just have to choose "else" once, and editor will remember your choice. It's actually recent feature of VSCode
https://code.visualstudio.com/updates/v1_19#_smarter-intellisense
Added to the list.
I'll probably slow down with work on new features in upcoming days/weeks, and switch my focus to other stuff. But keep reporting any issues you encounter - these are useful, as I don't work much with SC2 projects recently.
However, as a long term plans.. or rather ideas. I'd like to implement frontend debugging UI for Galaxy in VSCode ( https://code.visualstudio.com/Docs/editor/debugging ). Which would utilize default TrigDebug window as a starting point. Primary reason is to make new frontend convenient to use, because default one is not so friendly... perhaps it would be possible to come up with some exclusive features. Although SC2 binaries got really hard to RE during these years (and I never was good at that to begin with :| ). I gotta dig more to see whether something like this would be feasiable at all.
The other thing I'm considering is yet another Galaxy Language Extension - acting as transpiler. My focus on this would be on features meant to improve usability, while avoiding implementing dynamic capabilities like Galaxy++ did. As there's no easy way to emulate that - it quickly gets messy.
But seeing how low interest there's about Galaxy related things within community, it might be simply too late for such project. If I'm however wrong about that, I'm open for collaboration.
Previously known as: SomeoneTookMyNameTT
I have not use vscode before.
Now this is the best one for writing galaxy. Thanks for your work again.
You mean use vscode to debug Galaxy script? You want to write a VM for galaxy or run SCII and get data and control the game? BLZ start to add features for SE, so it will be a continuous work. If you finish it, it will be great! As we know, BLZ have never supported a good debug tool, no matter WE of War3 and SE of SC2.
I am a original-edition-ism user. It is a bad habit of caring efficiency from the period of War3. I do not like vJass, cJass and other extensions of Jass2, the script language of War3. But for SC2, galaxy is enough efficient. So I have never used the extension of Galaxy++.
It is just a habit. And I think you can add a support of write a class, which can add methods to a struct (just like a class in c++),as a further feature support the scope of methods and field of struct.
As you say, it may be so late to do this. I think I will not a user of it, but I think it is worthwhile. For War3 in China there are still so much mapmakers woke for WE tools, before the Class Team of BLZ continue its work of War3 in years. The fist thing is if you want and have enough time to do, is not if it so late. Is that right?
Ah, it crashes because it attempts to report an error (about missing value for return statement) on non-existing node.
Gonna release fixed version soon, in meantime you can just hotfix it, since it is JavaScript - no recompilation required :)
https://github.com/Talv/plaxtony/blob/157ecca13cfb4c04bf669068e4432e670619c984/lib/compiler/checker.js#L885
replace
node.expression
with just
node
Path to checker.js is in your logs.
Yes, plan is to use SC2 VM. Since SC2 already has debugger to control VM, I can utilize it by just hooking up relevant winapi controls.
Of course I'd like to go a little beyond that - inject some additional binary code to SC2.exe that would allow to for example modify values of variables. But that requires further research..
Yes, I wouldn't like to implement features that would noticeably impact performance.
I was thinking about features such as:
- modularity/namespaces: Galaxy has single global module and everything is put into the same namping space - included files can access everything what was declared by parent files..
- Tigger Library generation from Galaxy code
- some syntatic sugar for things like passing variables as references (Galaxy requires you to wrap it with arrayref), iterator interfaces to provide foreach loops
- maybe some C like preprocessing macros..?
etc.
I really think there's a lot that can be done to make Galaxy "more friendly" - reduce the amount of boilerplate code it often requires to accomplish simple things.
Well, we'll see if I'll be motivated enough to put needed time into this.
Previously known as: SomeoneTookMyNameTT
This can pass the syntax checking.
Thanks for reporting these, but if you've account on Github it would be probably better to report it there - I get the notification and such.
https://github.com/Talv/plaxtony/issues
As for the second one, if you move things around, you'll get:
What is valid code :) Unless SC2 Galaxy parser complains about something like that? O.o
Previously known as: SomeoneTookMyNameTT
In reply to Talv_:
In general whitespaces are ignored in languages where they are not used for indicating beginning and start of the block (such as Python etc.). Galaxy mostly follow C syntax, thus you could even do things like:
And it should work (it does in current version of SC2). But you might be right - I never tested how it did behave in the past.
Reporting bugs here is completely fine too. But I just respond to it slower, since I don't visit the site so often anymore.
Previously known as: SomeoneTookMyNameTT