Combine node null error

In the attached drawing, the quad curve is visible as the arc at far right, via combine1.

I'd like this curve to be copied along with the log spiral, so introduced combine3 and tried to move the spiral to its first input. But then get a null error. Could be another bug in my understanding, or possibly the system.

BTW, my first post about double clicking hasn't been an issue for some time, so that could be closed. My second and third posts indicate known and new bugs, respectively.

Hi Chris,

Before I could figure out your network, I had to clean it up. See before and after image (attached).

Aside: I have learned over the years how important it is to space out and align my nodes so that all the links are clearly visible and the overall top-to-bottom flow is readily apparent. I find it soothing to do this as I go - like flower arranging. But it's also deeply practical, especially when you come back to a network after a few weeks. A clean tree structure is much easier to scan than a hairball. This is the NodeBox equivalent to writing clean, well-formatted code in other languages.

The file you attached did not have the error evident, but I assume you meant the null error that would occur if you fed quad_curve1 (near lower left) into combine3.

If so, this is not a bug. It is a fundamental rule in Nodebox: no loops are allowed. Your network must be a tree with no cycles. You cannot feed the output of a node into any node directly or indirectly feeding into that node. (This is another reason for keeping your networks tidy: it makes such inadvertent cycles much easier to spot.)

In this case, the point2 port of quad_curve1 is fed by a series of nodes tied to the output of combine3. If you try to feed the output of quad_curve1 back into one of the inputs of combine3 you would create a cycle.

(I admit that the error "null" is not very helpful in describing the issue; NodeBox probably doesn't "know" there is a cycle, it only knows that something somewhere is not right.)

The solution is to define your quad curve independently of your log spiral and THEN combine them - which appears to be what you did.

Let me know if that makes sense. Looks like the thing you're making is pretty, by the way.

John

Thanks a lot for the cleanup and invaluable advice.

I’m a stickler for program formatting style, so readily appreciate your point. It takes time with an entirely new style of programming to appreciate what good style is, as most of it has to do with retaining program comprehension at larger scales. I had great difficulty impressing this on students who had no experience with large programs. Since Nodebox's visual network approach is entirely different from structured text, it has very different scaling problems. I have a large monitor, but eyes that are’t as good as they used to be, so I’ve been working to compress the structure to fit in limited area. I need to get comfortable with scrolling the network window, and when that’s too awkward, using subnetworks. I’d like to better understand the semantic effects of the latter.

Problems with cyclic structures are, of course, one of the most important themes in C.S., so I readily appreciate this limitation in NB (which I might have been clever enough to anticipate). I can’t imagine it not being explicitly checked for, so a more helpful message shouldn’t be hard. At the least, it should be mentioned in the How NodeBox Works section of the documentation.

In this network, the arc geometry needs to connect end-of-path points generated by the copy, and the arc itself needs to be copied in the same way (to complete the perimeter of the mandala). But it won’t be much harder to add another copy for that purpose, thus avoiding the circularity. NB would be much more powerful if it allowed circularities, such as I was trying to create, that converge after a few iterations. But that would slow it down and add to its conceptual and implementation complexity.

Chris

Chris,

I enjoyed your thoughtful comments and agree with all of them.

It does take experience to appreciate good style and NodeBox does have very different scaling problems. Many people use NodeBox only to make quick sketches, but I regularly use it to make huge networks with thousands of nodes that can run twelve levels deep in subnetworks; at that scale visual styling becomes crucial.

I also have eyes that aren't as good as they once were. At work I had a ginormous monitor that was a joy to use with NodeBox, but I have recently retired and currently do all my work on my laptop (which I'm used to). As a result I do spend much time scrolling and so try to strike a balance between compactness and clarity, but prefer to error on the side of clarity.

You are right that subnetworks are the key to keeping things under control - both clear and compact. When you start playing with them you will learn that they are not merely for encapsulating content, though. Their primary power is in controlling the choreography of signal transmission by determining whether each port should be read in one value at a time (value) or all at once (list). This is a subtle point, well hidden in the UI, that caused me much confusion when I was first starting out. I have written about it extensively in the forums. If you have any trouble, please seek me out and I'll help you master it.

NodeBox's rather severe limitations, no cycles, no state, no global variables, do create challenges, making some things which are easy to do in other languages harder to do in NodeBox. The silver lining, though, is that it greatly reduces the amount of debugging required. Even with very complex networks, bugs occur much less often in NodeBox and are much easier to track down. The really subtle killer bugs are not even possible. I became bone-tired of hunting for stray semicolons or mismatched braces in "normal" languages; once liberated from this I never looked back.

The one limitation I chafe against and have long complained about is the inability for NodeBox to do recursion. This is a curious omission in a Lisp-like language, and could be remedied without breaking the paradigm. I have found a few workarounds and have created things like Conway's Game of Life in NodeBox by writing and reading an external file. You can also create subnetworks which can be chained together to an arbitrary depth, which is good enough in some situations. If worse comes to worse, you can also resort to custom nodes in Python or Clojure.

I hope you will keep at it. You clearly have some deep insights into the potential power of NodeBox.

John

Thanks for these thoughts. Your experience with huge NB programs is inspiring! Only experience will give me a working feel for it, but your few words on subnetworks is helpful.

I readily appreciate the ease of debugging coming directly from the limitations of NB. In particular, experience with purely functional programming makes clear the advantages of the absence of state. Also the power of recursion, though my understanding of NB is still so limited I don’t understand just how that would be different from cycles; perhaps through reference to named subnetworks?

There’s a place for purely functional languages, as well as those like python/clojure/scheme that enable it but don’t enforce it. And those like SQL that don’t support general iteration or recursion, thereby loosing Touring completeness, but gaining guaranteed termination (easier debugging!).

It looks like NB development stalled some years ago, which seems a great pity. Not just NB3, but also NB1/2, which no longer work at all with the current MacOS. The visual style of NB3 is very powerful, but for some purposes a purely textual language has the greater power. Scaling problems have been largely solved in the latter context with modern OOP, library management, and IDEs.

Chris

Hi Chris,

Your comments are insightful. Clearly you've been around the block a few times.

One way to incorporate recursion into Nodebox without allowing actual loops would be to provide a "me" node. This node would be special: it could only be used inside a subnetwork and would directly reflect the properties of its parent. So you couldn't add or subtract ports from a me node and if you added or subtracted ports from its parent node, those changes would automatically appear in the me node as well.

Having a me node would allow you to create recursive code inside the subnetwork that included a switch node to serve as an escape hatch. Based on some criteria the switch would either return a fixed value or the output of a me node. So for example a factorial(N) subnetwork would compare to see if N < 2 and feed that into a switch node. If true, the switch would return a value of 1; if false it would return N multiplied by the me node fed with a value of N-1.

I once suggested this idea, but doubt we'll ever see it. It would not be trivial to implement and a purist might find it somewhat unNodebox-like, but it would allow NodeBox to do some things it can't do now. As I mentioned, I have found work-arounds over the years that allow me to simulate recursion within NodeBox, at least to some arbitrary depth. Where there is a will there is a way.

I also have to agree with you that NB development has stalled over the last few years. I am a one-man force fighting this, and often feel like Don Quixote tilting at windmills.

But NodeBox is not dead yet. Frederik just released the first update in years, 3.0.52, which fixes two troublesome bugs. It is the first post-Catalina update, incorporating Apple's more stringent requirements for notarizing apps under MacOS, which should keep NodeBox viable for awhile.

I have also just released an image node, which finally addresses the most common feature request over the years:

https://forum.nodebox.net/t/19506698/image-node

I am committed to keeping NodeBox afloat and doing what I can to extend its power through new nodes - at least until they haul me away. For all its faults, and even with the odor of decay now setting in, I still find it fun, simple, and surprisingly powerful.

I hope you will join me!

John

Thanks again for your replies. Very good to know about the new NB that won’t turn into a pumpkin soon due to apple security measures. In only nodebox 1/2 could be brought back to life. Appreciate your efforts making the most of what there is and helping others benefit. The image node looks cool!

About a month ago I got hooked into volunteer python program development for the non-proft Carbon Neutral Indiana (soon going national). This is very exciting, a good match for my skills, and a close to full time job! Hence my desire to get back to Nodebox hacking is on the shelf for some time, but I won’t forget it’s there.

Best,

Chris

Hey Chris,

Thanks for writing back. And good for you - sounds like you found a good gig.

As you're doing your Python coding you may still find some uses for NodeBox. It's particularly good at data visualization. Of course there are tools and libraries for doing that entirely within Python as well, but sometimes it's easier to use Python to generate a CSV and then import that into NodeBox to produce charts and graphs - or custom data-driven diagrams for home energy usage or whatever. Just a thought.

Good luck and drop by again anytime!

John

I’d had that thought as well. But we’re rolling out a website for each state, each with unique graphics. Is there a way to programmatically invoke Nodebox many times with different data?

Chris

I'm not aware of a way to programmatically invoke Nodebox 3, but it has been a common feature request. A few years ago a NodeBox user took a run at doing this and made some progress before disappearing. He left a pretty interesting conversation thread:

https://forum.nodebox.net/t/16490176/adding-socket-connection-functionality-to-control-editor

You can certainly make NodeBox produce visualizations in an entirely data driven way, but you would have to invoke NodeBox by hand each time. You can automate most of the process by, for example, reading in a whole folder full of different CSVs (e.g. one for each state), produce a different chart on each frame, and then export them as separate SVGs, PNGs, or PDFs all at once using Export Range. But that export would have to be done manually and the resulting files would have to be uploaded to a website manually or by using some other tool or chron job or whatever.

You can also import constantly changing JSON data over the web using the three network nodes and continually produce output by including a frame node and hitting play. It is also possible to include a node to output data files during such a process. I have used this to approach to repeatedly write text files. With some custom code it should be possible in theory to output other types of files and maybe upload them to the web automatically.

In other words, it may be theoretically possible to automatically populate websites with graphics using NodeBox as it currently exists, but these schemes strike me as being rather kludgy and I cannot recommend them. I think NodeBox's strength is in developing new kinds of data driven visualizations and maybe producing them as one-offs. I would not use NodeBox to run a website 24-7.

John

Thanks again for a bit of your deep knowledge of NB. One of those approaches might be useful in my new context. Too soon to tell, but I’ll save this and keep it in mind.

Chris