Aristos Queue

I encourage Ben not to worry too much about the interoperability with G and focus on getting the new language stabilized within itself -- a graphical notation for a safe reference system has value even if it only talks to itself... it can become an ecosystem just as G did. Now, obviously it has *more* value if it can talk to other languages, just as G has gained that ability over time. But that doesn't have to be up-front. Once the Rebar memory management is well-defined, creating the rules for interop should be relatively straightforward. I'd be far more concerned about Rebar cutting a corner to accommodate G than about making the interface seamless. The whole point of building an absolutely provable system is that it is provable -- any shortcuts and the whole attempt loses its value. Interop between Rebar and G will come in time.

I agree. Ben works on making a language safe for references. I work on making a language without references. Our goals are the same: a world where data can be trusted.

Ethan: Your CAR has been received, and I believe I have it fixed for LabVIEW 2019. Testing is ongoing to verify, but I’m confident. The in-place optimizations for class field access should I hope be addressed in LabVIEW 2019 if you have simple, inlined, static dispatch accessors that do not include error in and error out. We found a way to make the magic pattern that works for clusters apply to classes. Fingers crossed. Relaxing the block on access to class private data has even more gotchas than I expected, and not just at the technical level... since we do method substitution within the VIMs, if we allow access to class private data then it seems like we should allow substitution of the fields. But that is a pretty ill-defined interface that crosses the line to admit some of the hardest-to-debug C++ code. I’m opposed to admitting that to G language, even as I acknowledge its powerful notation. Even if I bought into it, I still don’t have a good solution to the technical barriers, at least not in LabVIEW 20xx. In LabVIEW NXG, it seems like it may be more viable.

Is that true in the recent versions? The typedefs got revision protection in LV 2015, I think. If the mutation is going to throw away data, it does the same sort of "relink" behavior as when changing conpanes of subVI so you preserve the data.

Short answer: Make it table driven. Long answer: As you scale up like that, you're entering the realm where you aren't going to code those values directly into G. You may be looking at an array of values in G that you loop over to create objects a binary file where you read back the objects you serialized earlier or something as complex as a SQL database with relationships between multiple tables and you process the entire database to create your object layout. These are just suggestions. There are many other options. The point is, you need to make your construction more data-driven instead of directly coded. This is true of all programming languages I've seen, not just G. The notation of objects is such that they come into being as data drives their existence. It's relatively easy to create an object with a given value, and if you're building up objects as they come into existence within a system, everything works fine. But to create an entire system of objects in one burst, you need a data structure that can describe an entire system. That's why things such as object databases exist.

The preference to use init methods instead of non-default class constants is so strong, LabVIEW NXG is planning to never support the feature. Any class constant there will always have only the class’ default value.

Definitely a bug. If you can share the code, it's worth escalating to an AE at NI to see if it is still broken.

I agree with Shaun. By the time you ship, of course, you shouldn't care whether auto error handling is on or off (your VI Analyzer tests caught those), but it is invaluable during early development. And if you did miss something (developer submitted a VI late on deadline and didn't quite follow procedure or test machine had a bad day and skipped a step of your build or whatever), having AEH enabled can save you a wealth of time.

So I have this bug report that AppBuilder fails to build this one particular app whenever the "remove polyVIs and typedefs" option is enabled. The top-level VI breaks during the build. I try some of our usual debug approaches and don't find anything, so I hack up AppBuilder a bit so that when I get to the end of the build, I can open up the broken VIs and see what they look like. And I see this: Where the heck have all the class methods gone? They're in memory at the start, missing at the end. That shouldn't happen! So I set up a trap to detect when the VIs go missing. I'm working in a debug build of LV with a lot of extra guards and logging turned on, so it takes about two hours to run this build. And I get nothing. So I rework my trap, thinking I've coded something wrong. Four times I do this over the course of yesterday, working on other issues while the build runs. Four times -- roughly 8 hours -- nothing. The VIs swear they're all in memory and the caller should know about them. This morning I come in and, for some reason, I happen to double-click on one of those ? nodes. And, lo, the missing VI opens. Say what? Turns out, AppBuilder had stripped all the VI icons out (saves space in the built EXE to ditch all those unneeded images), so they all render as the ? icon. I have no idea what's actually broken, but it ain't that all the class methods have gone away. One wasted day. *head bang* *head bang* *head bang* Yet another reminder -- as if I needed it -- that computers only do what we tell them to do. And they do it very precisely.

I decided my previous reply could be taken too snarkily... not what I intended. Let me be explain -- Ernesto is right, and with the lens he's looking through, it's a reasonable position. There's a rather substantial difference between a casual refactor that changed a terminal to be consistent with all other terminals and a foundational logic shift required to make two terminals that are literally the same address in memory return different values -- but that's something I can know with deep knowledge of the code underlying these two issues. No way for Ernesto or any other customer to recognize that. One can be done just by removing what appeared to be a bug; the other would require significant and deliberate retooling of the code. Not to mention it would break regression tests (tests that don't exist for automatic error handling since at the time that feature came along, there wasn't a good way to automatically test for anything that triggered dialogs requiring human acknowledgement). There are levels of trust between tool vendor and tool user, and once those are breeched, the promises of the vendor aren't worth anything. That's the case here. So even explaining all of the foregoing logic doesn't really suffice to say that Ernesto is wrong in his defensive coding practices. That's something NI has to earn back for that user. So perhaps if the bug with the auto error handling gets fixed and nothing changes about the errors of the accessors for another couple versions, we can get to the point where Ernesto feels comfortable removing the unnecessary bits. But until then, he's right to continue his current practice, and I shouldn't have said otherwise. I apologize.

Never mind. You're right. Sorry.

Yes, there is a guarantee: both a statement from R&D and also just how much code we'd break if that ever changed. But if you want to continue connecting both, it's just your own programming time and run-time performance you're wasting, so go for it. I'll file the bug report. Definitely worked when the feature was first introduced (thanks to TomOrr0W for checking back to 2009). *head bang* This has not been a good LabVIEW day.

Paul: Been thinking about this more. I think I can see how this works, but I'd love to see your source code to play with it more. If at some point we're at a conference together, I'd love to look at it.

Paul: Your response is exactly why I thought inheritance is a bad choice here. "D:Exit()" on a state is not a well-defined method because it's behavior depends upon context. Having "D:Exit()" that ONLY does the exit work of D and not the exit work of B or A means that the transition can call "D:Exit()" and then could also call "B:Exit()" if and only if the transition knew itself to be crossing that boundary. Or, better -- it would just call B:Exit() and let B know to call D:Exit(). It's all design time knowledge -- using reflection means that design time information is being computed at run time, which is both inefficient and error prone. I know that neither of the alternatives I just now suggested fits cleanly into your existing architecture. Your need for reflection is clear to me given your current design. And while I would consider your architecture as a use case if I were working on reflection, I would still push back on the architecture itself. To inherit, you need Identity, State, and Behavior. All three. If you don't have all three, you shouldn't be inheriting. You don't have Identity. State D is not a flavor of state B. It is a substate of B. Any time you miss one of Identity, State, or Behavior but choose inheritance anyway, somethings work, but other things will become significantly more complicated. And a need for reflection is a bright red sign.

I'm familiar with the State Pattern. I've just never seen the inner states implemented through inheritance of the outer states. I've always seen that as composition. Once I pulled it apart, it made sense. Let me see if I understand: If the transition is from one inner state to another inner state, you call a method X. If the transition is from one inner state to another state outside the outer state, you call a method Y ("StopMotion" in the example). Either that method is responsible for calling an abstract core functions to be implemented by the inner states ("OnInterruptProcessTriggers" in the example) OR (not in the presentation directly but seems to be alluded to) the inner states would override "StopMotion" to add the behavior they need for that transition and use Call Parent to make sure they get the common transition code. Assuming I have that right, it all makes sense. What I'm not seeing is why any of the function invocations have to be decided at run time. It's all fixed function calls to match your state machine model. You never have to find the "common parent" for a given transition because every transition has its own method (that is only implemented starting at a particular level of your hierarchy). Where does the dynamic come into play?