Project continuation

[makekryl]

Hello,

About a year ago, I took ntt's excellent parser as a foundation and built a fully functional, feature-rich semantic and type analyzer around it. This enabled me to create several useful tools for TTCN-3, including a work-in-progress static analyzer, a source code formatter, and a language server. It addresses some limitations of ntt and provides features such as import management, unambiguous "go to definition," and semantic and type error diagnostics, among others, with ASN.1 support out of box.

If you currently cannot allocate more time and effort to ntt, you may be interested in Vanadium. It is licensed under BSD-3 like ntt is, also nearly 2-3x times faster and more memory efficient. I wrote it not in Go but in C++ though, to have better opportunities to achieve the ultimate performance.

Currently it is not in VSCode Marketplace, but I have plans for setting up the release infrastructure this week, after sorting out READMEs, etc.

[5nord]

Hey,

It's beautiful!

However, I am not sure if we can allocate necessary resources to take responsibility for a third TTCN-3 project. I will discuss this with our team nevertheless. I will also talk to ETSI guys maybe they'll have an idea. We surely find a place for your work.

May I ask in what context you created this project? Is it "just" a hobby-project to see how fast one could possibly go, or do you also have users who rely on Vanadium in a more commercial context?

PS: Please excuse my slow reaction, I still have to accustom to the chaos three little kids can introduce in someone's life :)

[makekryl]

Hello,

I created it as a hobby project in my attempts to combat the slow edit-compile-run-debug development loop with the Eclipse Titan toolset (RT1 especially).

At first, I was hoping to make improvements to ntt, with my primary goal being implementing automatic import management, and contributed some patches here ~1.5 years ago, but I faced the necessity of implementing a full-featured semantic analyzer, which is a quite complicated task due to the TTCN-3 nature (imports and "runs on" specs that augment the responsive semantic scopes). Moreover for a decent language server with low latency, the analyzer must be incremental, which makes the task even more harder. I did not have a considerably large experience in compiler development, therefore, fearing the possibility of writing inefficient algorithms, I decided to implement the thing not in Go, but in C++, where I could amortize my somewhat dumb inefficient algorithms with reasonable low-level memory management strategies.

After a couple of months, I got it all figured out, and even managed to write some pretty clever (or not) algorithms, but I ran into a problem with enum scoping (the range of possible values ​​depends on the type of the operand). I had to write a type analyzer, and... I somehow reached the current state, where I would be happy to share my work with the community.

Regarding the commercial context, the LSP that was my original target (and the formatter) is now being used by my team for near a half of year with nice results. The corporation is not interested. So it is free both as in free and as in freedom!

Using Titan as a reference implementation, I've observed (sadly still never got around to writing the ETSI conformance test runner) that the semantic analyzer's accuracy reaches around 90% (currently, a couple of semantic checks are performed intra-module and not during inter-module linking, which is called "crossbinding" internally if you tried to dig into the code), and the accuracy of the type analyzer is around 85%. This already makes a solid base for writing the actual LLVM-based compiler, which I'm going to try very soon, as I now took a little pause to increase the fairly low test coverage of the existing code, with very fast compilation as the primary goal, and the efficient runtime as the secondary as viewing Titan runtime profiling traces is somewhat... sad from the performance point of view.

The formatter seems to be production-ready, and so is LSP, for the most part, except for any non-standard extensions to the standard or static polymorphism (although a couple of weeks ago, LSP crashed without a project manifest, and now it simply doesn't work without one, which is probably not a very pleasant welcoming experience, but I'll fix that soon too). The static analyzer is quite little useful at the moment; right now, it's mainly useful for automatically removing unused imports.

There's two reasons the extension is still not in the VSCode Marketplace: the first is Windows, which I guess should be supported, but that's will require some additional testing and fetching the LS binary instead of bundling it within the VSIX; and the second is the fresh requirement of giving your soul to MS Azure DevOps to publish an extension - I'm planning to publish it to OpenVSIX, but it can be always built from the source (and that's something I'd personally do instead of downloading a binary blob :))

So, what I wanted to say is that I'd be happy if anyone in the industry finds the Vanadium toolset useful, and you can always open an issue or send a patch if you need to make any changes upstream!

PS: the project name comes from the Periodic Table, V comes just after Ti :D

PS: Please excuse my slow reaction, I still have to accustom to the chaos three little kids can introduce in someone's life :)

That's totally understandable, thank you for the interest :)