Jump to content

Aristos Queue

Members
  • Posts

    3,178
  • Joined

  • Last visited

  • Days Won

    196

Everything posted by Aristos Queue

  1. To all things there is a season. Jeff Kodosky helped found National Instruments and invented LabVIEW. He inspired hundreds of us who shapes its code across four decades. But Jeff says it is time to change his focus. Today, NI announced Jeff’s retirement. He will probably always be noodling around on LabVIEW concepts and will remain open to future feature discussions. But his time as a developer is done. Maybe you didn’t know that? Jeff still slings code, from big features to small bugs. He’s been a developer most of the years, happy to have others manage the release and delivery of his software. I spent over two decades working at his side. He taught me to look for what customers needed that they weren’t asking for, to understand what problems they didn’t talk about because they thought the problems were unsolvable. And he built a team culture that made us all collaborators instead of competitors. Thank you, Jeff, for decades of brilliant ideas and staying the course to see those develop into reality. Your work will continue on as one of the key tools on humanity’s expansion to Mars.
  2. June 3 will be my last working day at NI. After almost 22 years, I'm stepping away from the company. Why? I found a G programming job in a field I love. Starting June 20, I'm going to be working at SpaceX on ground control for Falcon and Dragon. This news went public with customers at NI Connect this week. I figured I should post to the wider LabVIEW community here on LAVA. I want to thank you all for being amazing customers and letting me participate vicariously in so many cool engineering projects over the years. I'm still going to be a part of the LabVIEW community, but I'm not going to be making quite such an impact on G users going forward... until the day that they start needing developers on Mars -- remote desktop with a multi-minute delay between mouse clicks is such a pain! 🙂
  3. Correct. There's nothing exported about TDRs. It's an opaque hierarchy of types from outside of LabVIEW's core code.
  4. I_was_smarter_when_I_was_your_age Can be read two different ways. 😉
  5. I have been a community admin for another Stack Exchange site, and the difference in tone between the various sites astounds me. I didn't understand how much rides on the tone the admins take. Stack Overflow, the main Exchange, is really bad to the point that I have shadow accounts to ask questions there because once you ask what is seen by some as a dumb question, they follow you to your next question with "you're still an idiot" type comments. It's massively helpful when it is helpful and deeply insulting when it is not. But it doesn't have to be that way -- it's the choice of the admins for that particular Exchange site. There's a difference between one or two obnoxious persons shining a flashlight in your eyes versus a group of people with laser pointers and magnesium flares. In my experience, Stack Overflow is the latter form of hell.
  6. I'm honestly unsure how you missed it. If you have suggestions for what would have caught your attention, please share them. Yes, the primary announcement is here on LAVA. But there's signs at multiple booths on expo floor from the sponsoring companies. Many of us include slides at the end of our presentations (assuming we're presenting on a day before the event). Various people wearing LAVA badges are all over who will happily talk about it. But it is not an NI event, so it usually isn't in any NI communication. The event is generally filled at or near capacity with 100+ engineers. We would welcome more if you have ideas.
  7. But if I just search "LabVIEW" on Google, lavag.org isn't in the first five pages of results when I'm logged into Google, so it knows my interests. My results are similar (but not identical) when I use a non-Chrome browser with private browsing on a new virtual machine (I didn't take time to hide my IP address). That seems like some search engine tuning is in order.
  8. I skirted the edge of what I'm allowed to say in my last statement. I'm obviously not at liberty to share any numbers, nor can I speak officially for NI on that front, but I personally had no qualms about returning to the LV team based on the data I've seen, at least for now. The future is not as bright as I'd like, but it's good enough for me to keep working. The decline on LAVA is worrisome. I've also noticed the reduction. It might be indicative that all of our new user growth is in experienced groups buying more seats for legacy systems without onboarding more new hires. I worry about that. But there's several other factors that could explain it also: The annual refresh of users from NIWeek/NIConnect has not happened for two years. The forums on ni.com are significantly improved (not as nice as LAVA in my opinion, but good enough to not drive people away like they used to). User groups went virtual during pandemic, which means there are now many more places to go for expert input regardless of geography. The number of other support venues has blossomed -- Stack Overflow is now available to LV in a way that it wasn't just a couple years ago; internal support groups exist at far more large companies than in the past. And the LV population has diversified into non-English countries. So am I worried about the future? Yes. But do I think we are currently in a bad spot? No.
  9. LV's user base continues to grow. Not as fast as it has at some years in the past, but it still grows at a reasonable clip.
  10. I don't know if it's the same people, Matt, but I've encouraged a couple folks to jump over to the companies they were temping for because it was better for NI. NI's position with those customers was stronger for having an "insider" on their teams. There is only gain for NI when one of our G developers goes off to be a full-time G programmer for another company! I only worry when our top G developers leave NI *and* they leave G. 🙂
  11. Thank goodness I've finally got that promotion. Y'all were holding out on this until I went back to writing C++ code for you, I assume. ;-)
  12. Update to this post: My sabbatical has ended. I went from Blue Origin to Microsoft, but as of a couple weeks ago, I have now returned to LabVIEW development. At some point, I may put together a public summary of my experiences as a full-time G dev. For now, be assured that I am feeding that experience back into the feature backlog priority list!
  13. As Francois noted, no, you cannot prevent it. The default instances are useful in many sentinel and error handling situations -- think like NaN in floating point. The defaults can also serve a role similar to "null" but without all the dangers of open references. Details about design decisions of interfaces can be found here.
  14. The restriction on DVRs is the same for interfaces as for classes: it allows for constructor/destructor notation for by-reference entities. Please don't go hyper excited and think "Oh, this is the tool I should have been using all along." By-reference designs are fragile and prone to several classes of errors that by-value code cannot create. Stick to the wires where possible; use references only when nothing else serves! 🙂 Details here.
  15. Another VI I thought someone reading this forum thread might find helpful. This one calls the one I posted previously as a subVI. "Make Control Glow.vi" draws a fading rectangle behind the specified control. Save it and its subVI ("Offset Glow Rect.vi") to the same subdirectory. For example, here's a glow on a system OK button. Color and border thickness are parameterized. Saved in LV2020. Make Control Glow.vi Offset Glow Rect.vi
  16. Here is a helper routine that I wrote yesterday based on the other VI. It's the world's most inefficient way to draw a rectangle but it works, and if you're trying to do some sort of animation fade effect, you can do it with this by putting in decreasing opacity. Draw Blended Rectangle.vi
  17. You can't save for previous anything inside vi.lib. Just do Save As >> Copy to a new location and then save that for previous. (It's been that way longer than I've worked on LabVIEW, and I just realized I have never asked why. It's just "one of those things" that I picked up early in my career that became part of the mental landscape.)
  18. New in LabVIEW 2020: C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\picture\PNG\Draw Flattened Blended Pixmap.vi I didn't create this one. It is not in the palettes. I have asked that it be added in a future version.
  19. Yes. My current customer does. It is a primary use case that we are currently working around the obvious (and trivial to fix) bug in the toolkit.
  20. Allow me to rephrase then. Recording an array when passed a NAMED cluster is definitely a bug, regardless of the behavior of the variants.
  21. The fix is easy -- just get the names of the cluster elements and pass into the subarray instead of relying upon the Variant To Data node to capture the names.
  22. Our use case is nullable strings and nullable integers. We want to be able to differentiate between "this is the set value of the parameter (including possibly empty string)" and "this parameter has never been set, so defer to the default". So a cluster of variant correctly should record "null" for an empty variant and not-null for a non-empty variant. Recording an array when passed a cluster is definitely a bug, regardless of the behavior of the variants.
  23. Found two bugs in "Variant to JSON Text.vi". The fixed VI is attached, saved in LV 2015. Included in this is a whole lot of manual diagram cleanup to help me follow some cases I was trying to understand. I noticed that there are several calls to the To JSON primitive that do not have the "enable LV extensions" boolean wired up. I did NOT change any of those, but they may warrant a review. There are also a few places where the error cluster is dropped that I don't think it should be. FIRST Here's the test case for the major bug: Expected JSON: {"a":null,"b":null} Actual JSON: [null, null] SECOND A simple miswire: the LV extensions bool was wired to the pretty print terminal in the Waveform case. Variant to JSON Text.vi
  24. There are many links on the Internet to tell you how to configure git to use custom tools for VI. Many are wrong. Yesterday, I and another developer outside NI worked through the sequence and got it working repeatably on both of our machines. Here is the process. Save both of the attached files someplace permanent on your hard drive that is outside of any particular git repo. We used C:\Users\<<username>>\AppData\Local\Programs\GIT\bin _LVCompareWrapper.sh_LVMergeWrapper.sh Modify your global git config file. It is saved at C:\Users\<<username>>\.gitconfig You need to add the following lines: [mergetool "sourcetree"] cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVMergeWrapper.sh' \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" trustExitCode = true [difftool "sourcetree"] cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVCompareWrapper.sh' \"$REMOTE\" \"$LOCAL\" [merge] tool = sourcetree [diff] tool = sourcetree That's it. There are lots of ways to edit the .gitconfig from the command line or by using SourceTree's UI... if you know those ways, go ahead and use them.
  25. Dont misunderstand me: I think it’s a great toolkit, and I think it should be a G toolkit not a language primitive. I’m just finding it’s edge cases. 🙂
×
×
  • Create New...

Important Information

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