Jump to content

Ben Leedom

  • Content Count

  • Joined

  • Last visited

  • Days Won


Ben Leedom last won the day on March 6 2019

Ben Leedom had the most liked content!

Community Reputation


About Ben Leedom

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW NXG 2.0
  • Since

Contact Methods

  • Twitter Name

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @smithd, I updated the nipkg attached to the v0.1.0 release (at https://github.com/ni/rebar/releases/tag/v0.1.0-alpha2) so that it should install with NIPM 18.5.1. Please try it out if you get a chance and let me know if it doesn't install for you.
  2. Rebar will take yet another cue from Rust in the C interop case. Rust has the notion of an unsafe context, which can be either an entire function or a block within a function, and within which you can do certain actions that would be not be permitted otherwise, like using raw pointers or calling any kind of external code. The language basically says, "At this point you assert that you know what you're doing; I will still enforce some rules, but it's up to you to ensure that this C DLL isn't going to violate data safety." (You can read more about unsafe Rust here.) Once interop with arbitrary C
  3. This is a very good question, and while I will try to answer, at the moment I have mostly a hazy vision that I have not fully worked out the details of. My priority is and has been to elaborate a good design for the core of Rebar, then create enough of an implementation of it that you can do some useful things in it and can see a path towards other useful things. How much the design and implementation of Rebar/VI interop gets worked out will depend very much on how much demand there is for it. A VI calling a Rebar function should look about the same as calling a subVI. A Rebar function's
  4. I think it's important to distinguish between what the language semantics are and what the compiled code and runtime actually do. For an initialized shift register on a loop, its value for a particular execution of that loop is only accessible during and immediately after the loop; the language does not let you get that value at any other point, and the value will be overwritten when it is initialized on the next loop execution. (NB: I'm not talking about individual iterations of the loop, but the execution of the loop over all iterations.) The compiled VI does store the shift register value i
  5. Apologies for that! I failed to realize that NIPM 19 isn't publically available yet. I will try to spend some time creating a package that is compatible with NIPM 18.5.1 soon. And yes, I share your frustration with NIPM versioning. I go long enough without having to fiddle with NIPM on my dev machine that when I do I wind up reinstalling it from scratch almost every time. Fair enough! Over the last week or so I've been trying to get things into a presentable state, but I agree that there is a need for a lot more documentation and explanation. The overview you've been quoting was i
  6. Cross-posting from the ni.com LabVIEW forum: Hello! This is a brief announcement that there's a new community here: https://forums.ni.com/t5/Rust-and-G/gp-p/5381 I started this to discuss a project called Rebar, which is an experiment in combining semantics of the Rust language (https://www.rust-lang.org/) with G syntax, implemented as an addon for LabVIEW NXG. You can read more about it and find a link to install the addon over at the community. Please take a look!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.