Implementing class variables in Python

[Chris Warkentin]

I'm trying to do something where I see too many paths to a solution and am paralyzed trying to figure out the best route to take.

My blocks are creating methods in a class so there are normal variables within those methods but there are also class variables which are generated like 'self.<var_name>_val'

I've got something that works okay using a dynamic flyout and custom variables like:

    {

        "type": "class_var_get",

        "message0": "self.%1",

        "args0": [

          {

            "type": "field_variable",

            "name": "VAR",

            "variable": "",

            "variableTypes": ["ClassVar"],

            "defaultType": "ClassVar"

          }

        ],

        "output": null,

        "colour": 35,

        "tooltip": "Accessor for class variables.",

        "helpUrl": ""

    },

    {

        "type": "class_var_set",

        "message0": "set self.%1 to %2",

        "args0": [

          {

            "type": "field_variable",

            "name": "VAR",

            "variable": "",

            "variableTypes": ["ClassVar"],

            "defaultType": "ClassVar"

          },

          {

            "type": "input_value",

            "name": "VALUE"

          }

        ],

        "previousStatement": null,

        "nextStatement": null,

        "colour": 35,

        "tooltip": "Setter for class variables.",

        "helpUrl": ""

    }

The problem is that these now all have a type of 'ClassVar' which means they can't be used dynamically like regular Python variables. For example these vars might be strings or ints or whatever so I'd like to use them in blocks that take numbers and text but they get rejected in some cases because the type doesn't match. I defeated SOME of that by removing "check": "ClassVar" from the setter which allows anything to be assigned to them but the getter still has the problem.

I'm now deep down a rabbit hole looking at overriding behavior of field_dropdown or subclassing field_variable but they all seem problematic. The biggest issue seems to be a chicken and egg one. How do I store the list of class variables to dynamically populate the dropdown?

I'm hoping someone has a suggestion I'm sure there's an optimal way to do this but most of the paths I'm looking down seem fairly complicated so I don't want to run off in the wrong direction.

cheers,

Chris

[Chris Warkentin]

I forgot the other annoying thing. These class variables also show up in 'regular' variable dropdowns and then they just don't work.

[Chris Warkentin]

From https://github.com/google/blockly/issues/1921 it seems the decision to show all variable types was deliberate:

"The recommended way to only show variables with the empty type is to add "variableTypes": [""] to the default getter and setter. The variables docs have more details."

Is there any way to do this at runtime rather than by modifying the Blockly source code?

[Chris Warkentin]

Answering my own questions but still no idea about the original problem. Apparently this works:

Blockly.FieldVariable.prototype.oldSetTypes_ = Blockly.FieldVariable.prototype.setTypes_;

Blockly.FieldVariable.prototype.setTypes_ = function(opt_variableTypes, opt_defaultType) {

    this.oldSetTypes_(opt_variableTypes, opt_defaultType);

    if(this.variableTypes == null) {

        this.variableTypes = [''];

    }

};

Is this wacky or okay?

[Chris Warkentin]

Just to not leave a thread dangling, it seems like I have a satisfactory solution. The variables are separate and I seem to be able to use them as expected:

If anyone is curious, we're building a machine vision/AI plugin generator for our smart frame grabbers. We'll use Blockly to create image processing routines using OpenCV and pass results to various AI algorithms in TensorFlow. Blockly will also be generating the GigEVision interface to customize the device when being controlled by industrial controllers.

I'm just getting started so I'll surely be back with more questions.

cheers,

Chris

[Beka Westberg]

> If anyone is curious, we're building a machine vision/AI plugin generator for our smart frame grabbers. We'll use Blockly to create image processing routines using OpenCV and pass results to various AI algorithms in TensorFlow. Blockly will also be generating the GigEVision interface to customize the device when being controlled by industrial controllers.

That sounds really cool! I'd love to hear more about it :D Eg what is a smart frame grabber? I did a bit of googling and it sounds like a frame grabber is a program that analyzes video, but I'm still not sure.

> I'm just getting started so I'll surely be back with more questions.

Oh yeah questions are always welcome! And thank you for posting your solution by the way. It's always really nice when you're searching for a solution to a problem and the original poster came back with a solution =)

Best,

Beka

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/fb6816f6-ebe3-488b-98fc-7b6f710840bfn%40googlegroups.com.

[Chris Warkentin]

Frame grabbers in general are interfaces between cameras and computers. Most industrial cameras use point to point protocols such as camera-link and use proprietary serial protocols for control. Our frame grabbers use protocols such as USB3 Vision and GigE Vision which allow simple streaming and control of these cameras. Typically these are FPGA devices designed for extremely high performance.

We're now branching into software based frame grabbers running on such platforms as NVidia Jetson which still provide the same functionality but MUCH more flexibility in terms of the types of cameras they can connect to as well as what can be done with the images.

We provide a means to write custom plugins in python which can do processing of the incoming images. An example use case is retrofitting existing GigEVision (GEV) cameras in a factory. Imagine you've got very expensive infrastructure that you want to 'upgrade' to use AI. Rather than replacing the cameras and computers, you can drop one of our devices in between the camera and computer. It connects to the GEV camera, mirrors its interface to the computer and does arbitrary image processing between reception and retransmission.

We're using Blockly to provide a simplified plugin development process. Many of our customers have little or no machine vision/AI experience so we're hoping to give a very simple workflow towards developing basic object detection and classification routines. A lot of what I'm currently doing is wrapping OpenCV functionality.

cheers,

Chris

[Beka Westberg]

> Rather than replacing the cameras and computers, you can drop one of our devices in between the camera and computer. It connects to the GEV camera, mirrors its interface to the computer and does arbitrary image processing between reception and retransmission.

Oh ok that makes a lot of sense! 

> We're using Blockly to provide a simplified plugin development process. Many of our customers have little or no machine vision/AI experience so we're hoping to give a very simple workflow towards developing basic object detection and classification routines. A lot of what I'm currently doing is wrapping OpenCV functionality.

That is so exciting! I love hearing about Blockly being used in commercial/professional projects (because usually you just hear about education projects). I especially love it when Blockly is being used to give people a more powerful way to interact with their devices (like you're doing with wrapping your python plugin interface).

This sounds like a really cool project! Thank you for sharing about it :D

--Beka

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/b2cc2123-a158-4321-a145-344c4f8dfb94n%40googlegroups.com.