I would love it if the red error box feedback could be differentiated between primary sources of an error (the location where there is an error in the actual patch) and secondary sources that just contain references to the primary object in error.
Because sometimes one small error on a common object can make your entire application turn red which does not help tracking that issue down.
We reviewed the topic.
The storytelling now goes like this:
VVVV is unmatched in its combination of
letting you express yourself in a language that detects typing errors early and thus is able to guide you with typing errors on links and data hubs, while
still letting you iterate fast by being able to test those parts of your program, that don’t have a problem
So that’s our insight: You want the errors in order to be able to track down potential bugs early, but you also want to be able to work and test refactored versions of your patches before solving each and every single issue.
But you are completely right, that red node applications and red node definitions all over the place are not helping when it’s about
finding the actual issue
estimating the real amount of problematic patches
We, therefore, now mark patches as red if they contain errors. They still partly run. But to find the error we figured you want those nodes to show up in red. All the others, that are further away from the initial issue - nodes that only use nodes that have errors inside - are now considered as worth having a look at. Thus we put a warning on them (making them orange).
From a definition perspective, we mark Categories in red that contain red definitions.
Can you add what the quickest way to find the location error is? How to know where the definition with the error is? Especially if the definitions are placed deep in the runtime patches themselves.
I just send Elias a project (concerning another issue). The patches there have a lot of cyclic dependencies. Try creating an error somewhere deep inside one of those patches and then hunt it down.
Should be a good test case.
I didn’t have that deep look at your project yet, but I am wondering if you ever tried to get rid of those cyclic dependencies?
I can only imagine that on a project of some larger scale rearchitecting the system is a very difficult task… But might still be an interesting exercise to at least try it on paper. What would be possible - in theory?
The thing with everything depending on everything is that it’s getting harder and harder to change bits.
If this is infeasible there is yet another thing that could lead to less cyclic dependencies:
Find one or a few types that you often use to hop from one system department to another. Try to do those hops via interface calls. Your patch now depends on the interface, but not the implementation. When done on a central type this abstraction could immediately give you
faster compilation time
less orange nodes
But these are just ideas for stuff you could try independently from us. We still tackle the topic from our end.
I appreciate the improvements so far in 2022.5.0. The ‘error is deeper’ functionality is already a big improvement. I also agree that best solution would let you jump to the error, possibly from a list like an ‘error explorer’. (Or from an error highlight on the solution explorer?)
In terms of the proposal to adjust architecture to remove cyclic dependencies, I think on most jobs that is going to be architecture priority 4 or 5 at best.
Realistically on a rapid prototyping job I will not have the time to achieve priority 4 or 5.
If my application is to process FOO and BAR then I’m simply going to reference those definitions a lot.
Adding an interface and casting abstractions iFOO and iBAR generally takes me further away from understanding how data is flowing through my application and what could be going wrong.
But I will give it a try next time I’m at that point and will add that experience to this discussion
Yes, 100% agree, I’ve never worked on a real-world project that even reached priority 3… It is important to differentiate between developing a library for reuse by others and an “end-product” with an approaching deadline. The rules and what kind of consideration goes into the architecture are quite different. The final software is/should be allowed to break any rule and use whether works in the shortest amount of time (also considering the skill of the developer).
