simple auto-node

[Spaced-out-games]

I'm working on making a node lib for this (mostly integrating already-existing libraries into Ryven) and I don't feel like defining each of them by hand, so I was thinking that maybe you could add a simple-auto-node method

The simplest definition of a node is as follows:

class SimpleNode(Node):
	"""docstring"""
	title = "title"

	tags = ["str"]

	init_inputs = [
		NodeInputBP(dtype=dtypes.Data(default=1))
		]
	init_outputs = [NodeOutputBP()]
	color ="#HEXCOL"
	def update_event(self, inp=-1):
		input = self.input
		result = input
		self.set_output_val(index,result)

I started making an algorithm that takes in a function and outputs something like this, but I never finished it. Plus,such an algorithm would make prototyping much, much quicker.

[leon-thomm]

I want to make the general remark that often when you want to automatically parse functions into nodes, you are already at a level of detail that should not be exposed to this level of visualization. However, there are still many cases where this can be useful, but it should rather be seen as a starting point to generate a template code that can then be optimized further, instead of a complete start-to-finish workflow. This should be easy to write, for some inspiration something like the following should get you starting quickly:

import inspect

def node_from_function(name: str, call: str, obj: object, color: str):
    """Create a node class definition from a given function.

    Parameters
    ----------
    name: str
        Becomes the title of the node.
    call: str
        Represents the full function call without parentheses, e.g. `math.sqrt`
    obj: object
        The function object. Its souce will be parsed using the inspect module,
        which might not work for some functions, expecially those of C bindings.
    color: str
        The color hex code the node will get.

    Returns
    -------
    node_def: str
        The code defining the node class.
    """
    
    try:
        sig = inspect.getfullargspec(obj)
    except Exception as e:
        raise Exception(f"Could not parse source of {name}.")
    
    inputs = '\n'.join([f"NodeInputBP('{param_name}')," for param_name in sig.args])
    node_name = f'{name}_Node'

    node_def = f"""
class {node_name}(Node):
    \"\"\"{obj.__doc__}\"\"\"

    title = '{name}'
    init_inputs = [
        {inputs}
    ]
    init_outputs = [
        NodeOutputBP(),
    ]
    color = '{color}'

    def update_event(self, inp=-1):
        self.set_output_val(0, {call}({
            ', '.join([f'self.input({i})' for i in range(len(sig.args))]) 
                                        }))
"""

    return node_def

E.g. node_from_function('sqrt', 'math.sqrt', math.sqrt, '#aabbcc') would give you

class sqrt_Node(Node):
    """Return the square root of x."""

    title = 'sqrt'
    init_inputs = [
        NodeInputBP('x'),
    ]
    init_outputs = [
        NodeOutputBP(),
    ]
    color = '#aabbcc'

    def update_event(self, inp=-1):
        self.set_output_val(0, math.sqrt(self.input(0)))

This code uses inspect to get the arguments of the function, which only works for functions that can be fully inspected at Python level; e.g. math.hypot cannot be parsed this way. Feel free to improve it and post it here, I may update the code then.

[Spaced-out-games]

crap, the tabs didn't work

[leon-thomm]

crap, the tabs didn't work

fixed it :)

Currently, there's no such repo, although I really really want this. There just hasn't been enough content so far; most node packages created so far were either closed source or designed for one specific use. The only existing large and somewhat maintained package that is designed for general use is the PythonOCC package. Though, if you are creating these large general-purpose packages, it probably makes sense that I do this soon...

[Spaced-out-games]

From what I understand, Numpy is fair game, given the license is included

Source: https://numpy.org/doc/stable/license.html

Also, the package I'd write would not be distributing the source of NumPy, just implementation of it (my package is useless unless the user has NumPy installed), but still better safe than sorry, ill provide the license in the project folder

[leon-thomm]

Ah, don't worry if you're just using the numpy python library, that is not "redistribution of source code". You can (and should) choose the license that you want to put on your code.

[Spaced-out-games]

I'm honestly quite new to licensing things that I make, since all of them are amateur and my own projects, just to learn the ropes I'm thinking open-source w/credit is my way to go since the entire intent is to make machine learning accessible to everyone, using your framework. it should be pretty straightforward, generating code, testing them, and trying to fix whatever bugs I come across. Plus, since Ryven isn't picky about datatypes, there's no need to define the pins of the nodes as certain types. Thank goodness

[Spaced-out-games]

I'll probably hand-code a visualize() node that draws a graphical representation of data-driven objects such as numpy.ndarrays, or torch.tensor

[Spaced-out-games]

@leon-thomm See above. Also, am I bothering you with all these posts? Maybe I'm talking too much

[leon-thomm]

No don't worry, we all need a place to learn and brainstorm on concepts we are not really familiar with just yet. GitHub Discussions is finally a good place on github to do that, much better than e.g. issues. It might just take me some time occasionally to answer when there's too much to do, apologies in advance. I do read everything eventually.

The *args syntax is not what you think it is, it's pythons way to denote an arbitrary number of arguments. For example

def foo(*args):
    for arg in args:
        print(arg)

takes any list of arguments and prints them. For example foo(1, 2, 'asdf', 42.1, False, ('t','u','p','l','e')) is totally valid. The * operator is used because it also relates to tuple unpacking (the list of arguments is just a big tuple, in the case above we can refer to this tuple through args). An analogous principle applies to keyword arguments, denoted as foo(**kwargs). This should give you enough keywords to quickly google for the remaining details.

Therefore, for functions with a variable number of inputs, one could argue to also make the node have a dynamic number of inputs as well. This, however, introduces state; your node becomes stateful, which itself is supported and necessary for all kinds of sophisticated nodes, but it heavily complicates development and introduces a huge domain of possible hard to find bugs, so yes we might just give it 1 input and we can still make an additional node Gather which simply bundles multiple arguments for a function and nothing else (so it is simple and easy to debug).

Regarding speed, this is most likely not a Ryven issue. Importing nodes is as fast as your node package is. I used large packages which loaded really fast, so if it takes ages there might be an issue with your code, or your dependencies are just very large (which I can't do anything about)

[Spaced-out-games]

ah ok. When it comes to tuple unpacking, its something I already knew, but just couldn't spit it out right, lol. Pytorch is definitely a gargantuan-sized package (there are more than a thousand methods and objects, which themselves have methods and objects inside)

Maybe I can separate them into sub-packages? Commonly used methods like torch.from_numpy and torch.Tensor could be in default.py, while the lesser-used methods can be in a file called extras.py. It would make loading less of an issue.

Now that I think about it, maybe the node importer can be asynchronous because the problem is that Ryven is unresponsive while importing.

One thing Ryven is lacking is built-in support(discussion #109). I could implement those datatypes relatively quickly, assuming there aren't 1000 methods on str() lol. Another is that nodes are not able to be deleted. All nodes are given four options automatically, why not add a fifth?

anyway, I'd better get back to schoolwork; ill work on this all later

[leon-thomm]

While there is currently no way to define actual hierarchies of packages (of course you can distribute the sources into different files and python packages as you like, but they still have to be imported when the nodes package is imported), you can

• simply define different packages (brings the advantage of pushing you to make the packages modular and independent), or
• import dynamically

For the second approach you can really go crazy by distributing the different PyTorch-subpackage-specific nodes into different respective python modules and write them such that the pytorch sub-package is only imported when any of the nodes is instantiated, not before, and then you have again one single ryven nodes package but pytorch sources are imported on demand; but that might be overkill.

Now that I think about it, maybe the node importer can be asynchronous because the problem is that Ryven is unresponsive while importing.

Hm, yes that's a good point, though I'm not sure how difficult this would be.

[Spaced-out-games]

asyncio...is honestly horrifying

I wish you could make a file that is a self-contained thread and then asyncio. run that file. It would honestly make developing with it easier

[Spaced-out-games]

@leon-thomm
Alright, so I've got a stable Ryven auto-node up and running. It can convert functions into Ryven - ready nodes. You can find it here:
https://github.com/Spaced-out-games/Ryven-Package-Manager/blob/9c84b6dd2514390e2c783b42d535221a88357765/tools/code_gen.py

It should theoretically work for every function(even non-python ones), but the (non-python) nodes will have nameless arguments.
It only works for individual functions and methods at the moment, and the plan is to add the ability to nodify an entire module, recursively. I tested it on the math module and it worked pretty well - Just needed a few fixes(now implemented into the function natively) and some import statements on the top and bottom and it's ready to go!