Truth is its a developer tool that just provides basic logging for debugging. Its not sexy, and its not actually shipping out of the shop. Just a few members of my dev team have adopted it. And it was written on company time, so the company technically owns it.
I Work in an aging framework for electronics testers written in a combination of C#/VB/LabVIEW its highly asychronous nature make debugging the system an issue.
"And it was written on company time, so the company technically owns it."
I figured this and you possibly breaking the rules were the reasons for discretion. I also figured you were forced to use aging crap that motivated you to try alternatives. A painful, but common, thing in industry. Hence, me reminding the other commenter not to expect a source reference on it. ;)
"I Work in an aging framework for electronics testers written in a combination of C#/VB/LabVIEW its highly asychronous nature make debugging the system an issue."
I usually try to drop papers or articles at moments like these but have nothing relevant. There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. I did find a few resources. Would have to know if the problem is communications, data, what before I could attempt suitable references for you.
You probably already do one of my base recommendations here: tracing flows and input validation on them. The equivalent of asserts on input and/or monitors with read access to global state comparing data/states against ranges or rules in a policy. Taint-methods are also helpful where you tag data in the datatype with details about where it's been and whats happened. That's more advanced and I'm not sure there's libraries available for those platforms. The other technique they can easily handle: I did it in VB long ago.
"Screw diamonds: legacy systems are forever."
That's friggin' great. Need to make a meme image out of that with some COBOL or RPG on it. :)
> There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify.
GRR isn't hard just time consuming. Yes its not fully verified
>I also figured you were forced to use aging crap that motivated you to try alternatives.
I'm actually a polygot programmer trying to pay the bills. Working in aging tester frameworks pays a lot more then web development. I like Rust b/c its basically C-With-A-Type-System. Its still very easy to reason about how the Cee-LangVM will handle your code.
But yes. Working in a code base from the 80's and switching to Rust is lovely.
:.:.:
The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line.
"GRR isn't hard just time consuming. Yes its not fully verified"
I believe it now after pulling papers. I even know exactly how hard it is and what parts are decidable.
" Working in aging tester frameworks pays a lot more then web development."
Makes sense. It's why I advise against commodity jobs. The niche or unpopular stuff usually pays better. Not always, but usually.
"The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line."
Hmm. That's more straight-forward than most async. Just detail-oriented work as you said. The taint idea of tracking exact sequence of mutations combined with design-by-contract tracks of function call contexts would certainly help that. How much I can't say as your combination of tech obscures it. Don't know enough Labview mainly. Microsoft has things like Spec# and verifiers for C# part with VB6 easy to ignore if you keep logic out of it.
So, you're in better shape than many doing multi-language, legacy work. At least as far as verification concerns.
Don't learn it. Its a terrible language, and a worse IDE. Yeah you'll learn over 6 figures with 2 years experience. But you'll waste a lot of time debugging issues with the runtime itself, also the langauge itself isn't consistent which can lead to extreme headaches/development lagging. But NI will compensate lost development time with free hardware so companies love it.
The tools for tracing/testing in Labview are annoying and kinda primitive. Hence why a separate callable logger is useful. Mainly in Labview all functions start out as heap allocated monands wrapped in a mutex. So basically every function has state initially. You then have to opt-out of this to get a pure function.
>Hmm. That's more straight-forward than most async
Well yes. We're not exactly concerned with verification of the asynchronous system. Just making sure everything happens in the right order, and each thread is actually doing what its commended to do.
At a certain level you can abuse asynchronous systems to make certain measurements easier. Just assume your input has a half-Gaussian input lag level, and suddenly a 200 sample moving average becomes sufficient for smoothing data not jumping though hoops of fire doing weird data synchronization.
"But NI will compensate lost development time with free hardware so companies love it."
WOW! I never even thought about that business angle to dealing with shoddy tech. Thanks for the warnings.
"Well yes. We're not exactly concerned with verification of the asynchronous system. Just making sure everything happens in the right order, and each thread is actually doing what its commended to do."
Glad you at least have an easy approach to dealing with that nonsense. :)
OK. So, thanks to your comment, I looked up a bunch of CompSci and stuff on asynchronous verification to see what old and cutting edge methods are. Looks like it's a mostly solved problem at the conceptual level. Even found a method from NASA for Globally-Asynchronous, Locally-Synchronous (GALS) which I keep stumbling into in hardware.
So, good news, there's a number of techniques for various aspects of this at a range of mathematical abilities. Might be able to make an informal, knock-off of one or more for your use case. The bad news is that I found more papers than I wanted to thoroughly read. Not filtering them myself. If you want, I'll drop you a link to an archive or links to individual papers for you to skim at your own pace. If not, that's cool too as I needed them in my collection anyway for high-assurance, asynchronous systems. Especially given all the uptake on async in mainstream.
So, it was great you replied with those details regardless. Might have inspired a future, bullet-proof system in an unusual instance of the Butterfly Effect. ;)
"Actually managed to sneak some Rust into production."
"...sneak some Rust..."
"...sneak..."
There's your answer on that one. ;) Others might be quite useful, though.