Tomi Maila

Luminar Technologies, Inc. is currently seeking applicants for a LabVIEW Developer to join our growing team in Orlando, FL. Our vision is to power every autonomous vehicle with the first LiDAR capable of making them both safe and scalable. It’s easy to get an autonomous vehicle to work 99% of the time, but it’s the last 1% that’s preventing them from becoming a reality. That’s where we come in. We’ve built a breakthrough LiDAR from the chip level up, delivering 50x better resolution and 10x longer range than the most advanced LiDARs available today. Luminar is not just a sensor, but the core of a platform that can enable the industry to have safe autonomous vehicles on the road. We are a diverse team of passionate and driven individuals, making us a powerhouse of innovation, design, engineering, and manufacturing. We are hiring the best and the brightest to accelerate the industry, and bring forward the next transportation revolution. Apply online by clicking the link below. APPLY NOW

At JKI, we have found that a professional user interface design can make a huge difference for LabVIEW applications. That’s why we’re very proud to announce we have just released the JKI Flat UI Controls for LabVIEW, a beautiful, professionally-designed set of LabVIEW controls that we use on some of our own projects at JKI! We hope that by sharing these with the community, we can help make it easy for just about anyone to build their own beautiful and intuitive user interfaces in LabVIEW. Learn More & Download

ShaunR, the List type in your example is not strongly typed but generic. That means the type of the list wire for a list of Strings is not different from the type of the list wire for the list of DBLs. That's the exact problem type parameters would solve. Hooovahh, although the data type is strongly typed , the data type of the circular buffer is not encapsulated into a "Circular Buffer of type String" class but instead it exposes the private data to outsiders. Further one cannot create a type definition or a class that one can use in a VI front panel to tell that this VI expects a "Circular Buffer of type DBL" as input and returns a "DBL".

Generics without type parameters don't really solve the main programming problem I want to solve: Create class libraries that can be used with different type data. As a simple example creating a class library for a linked list of data of any type would not be possible with VIMs be cause they couldn't output a type parameterized type "Linked List<T> " where T is the datatype and Linked List is a class having T in the private data. Now T is a type parameter so we need to represent it somehow. VIMs don't provide a representation for type parameters in data structures.

I recently posted a more detailed LabVIEW Idea Exchange post related to this topic. Check it out and kudo it so that we get type parameters and parametric polymorphism to LabVIEW.

I made the Adapt to Type method public in JKI JSON allowing separation of the parsing from a JSON string and adapting to a LabVIEW type. It's not yet documented but if you look into JKI JSON Deserializer class the behavior should be relatively obvious. First deserialize from JSON string and then call adapt to type when you know what type you need. Thanks drjdpowell for the suggestion!

We recorded all JKI presentations and have made them available online. AI and deep learning with Javier Ruiz & Ian McFarlane, .NET integration and interface design with Sarah Zalusky, and Caraya unit testing with Jim Kring. Good stuff! Caraya: A New Take on LabVIEW Unit Testing - TS9754 by Jim Kring Designing a LabVIEW Interface for .NET Applications - TS9757 by Sarah Zalusky Artificial Intelligence With LabVIEW: Deep Learning-Based Classification and Control - TS9758 by Javier Ruiz & Ian McFarlane Watch videos

Are you using typedefs or LabVIEW classes in your cluster?

I always love a small challenge. Here's what I did: Calculate the offset of first pixel of each row in the final image where offset is the index of an element in the initial U64 array (this needs to be calculated only once) Initialize a destination image of correct size For each row of the destination image, replace the row content with an unpacked content of the initial U64 array of correct length I was able to drop the processing time to about 1/2 of the fastest algorithm in the initial VI. Download here p.s. LAVA refused any uploads...

When I originally selected the name for my blog ExpressionFlow back many years ago, what I had in mind was functional dataflow programming and the ability to pass any subdiagrams (expressions) around as first class citizens of the language. Functional programming languages (haskell, clojure, lisp) have a lot in common with dataflow world. In principle, calling a function in a functional language is identical to calling a node in a visual language. Passing data between functions happens in an immutable way in functional languages, similar to the concept of data flowing between nodes in a flow-based programming languages. Monads determine execution order of functions with side effects, the same way as flow diagrams determine the execution order of nodes in LabVIEW. Functional programming is often seen as an alternative to object oriented programming. One can solve similar problems of dynamic dispatching either by passing functions around or passing objects with methods around. There are of course multi-paradigm languages supporting both objects and functions like Clojure and Scala. So what would LabVIEW look like if it supported concepts of functional programming paradigm? I posted an article on this on ExpressionFlow and I am intending to study the concept on ExpressionFlow in my future posts. Would you use functional LabVIEW if such a language existed? My post on how a functional programming could appear in a visual dataflow language: Synchronous Functional Dataflow Programming & Closures of Named Functions p.s. See Joel's quick intro to functional programming if you are unfamiliar with the concept of functional programming.

I actually really like the message passing concurrency models such than the one of Erlang. The good news is that the flow-based programming models actually rather well help architecting such models using a visual programming language. The downside is that such languages are not widely available as of today. Read my last few posts on convergence of asynchronous and synchronous dataflow models. Hybrid Dataflow – Convergence of Flow-Based Programming with Synchronous Dataflow Embedding synchronous dataflow into a flow-based programming diagram

Thanks, I try hard to stick around this time

All, I am happy to announce that I am back in blogging on ExpressionFlow. I'm trying to cover more theoretical topics around visual programming and discuss new fresh approaches. I'd like to invite everyone to follow the blog and @expressionflow twitter account. url: http://expressionflow.com twitter: @expressionflow facebook: https://www.facebook.com/expressionflow Please let me know the kind of topics you'd like me to discuss. There's lots of cool topics on my mind already but I would love to hear from you, what would be something interesting for you all. Thanks, and happy Thanksgiving for everyone! Tomi

Would you like to report this to NI as a bug on application builder.