John Lokanis

I am seeing the exact same issue in LabVIEW 2024 (24.1.1f1) 64 bit version. I am trying to build an application that works fine in LabVIEW 2020 but gets this same error 13 with the same description: LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format. ========================= LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format. ========================= Shareable board exclusively owned. Method Name: Linker:Write Info To File Was the bug fix applied to the 64 bit version or do I need to wait for another patch?

Does anyone know if there was a change in the format of the NI Week conference this year? I am presenting and my session was scheduled for Monday afternoon. I don't remember there being any sessions on Monday other than for Alliance members (of which I am not). Seems odd. Anyone have the scoop on this?

Looking for info on the BBQ signup this year. Google came up empty. Is it still happening?

And they spelled LabVIEW wrong. Not sure if this person intended to use this for the same purpose you are intending.

Back to the original topic: What is the best way to share reuse code that other code depends on? My reuse code is deployed in user.lib so that it appears in the pallet and can be found by quick drop. I have seen some suggestions that reuse code should be in the project folder for each project. This seems to be more portable but then leads to multiple copies of the same code on your system, making maintenance difficult. Another issue is using SCC with code in the user.lib. You don't really want your SCC system to be placing files in your program file directory. So, you end up with storing the code elsewhere for maintenance and then needing to package and deploy it after each edit. This make adding new functions and fixing bugs cumbersome. So, what solutions have others used? What are the tradeoffs? And what process should we adopt for reuse libraries we wish to share online? I would like to find a solution where we can get the benefits of the code being in user.lib without having to keep it under the LabVIEW installation folders.

That is a good point. The code I would want to share includes one-off examples, reuse libraries and full frameworks. Not sure how to deal with all the dependancies. It seems like you would have to first share all the reuse components before you could share the higher level projects that rely on them. Also, how should we be packaging the reuse libraries? VIPM packages? Source code distributions? Zip files? And what level of documentation and testing is going to be expected and accepted? I think we need to come up with a baseline of what shared code should include so it has some value and is not too hard to use. But I guess we could let the market decide that. I would still like to hear what everyone thinks is needed at a minimum.

One of the main topics of the 2018 CLA Summit was the need to improve access to open source code in the LabVIEW community. This is something that I have tried to do in the past with limited success. After hearing what others are doing and discussing the issues, I am inspired to take on the task of getting as much of my code that is shareable out into the open for others to use, improve, learn from and critique. So, the point of this thread is to figure out how best to do that. I have tried posting code to forums in the past. I have even posted to the code repository here on LAVA. I have used code posted here and via the tools network and VIPM in my own projects. But I am not sure if any of those avenues are the right path forward for me. There was much discussion about different open source repositories on the interwebs that we could leverage. There was also some discussion about how to help others discover the code you shared. What I did not hear was any definitive conclusions on how best to do this. So, the point of this thread is to try to solicit feedback on code sharing and come to some sort of consensus on the best options out there. If you have an opinion on this please join the conversation and share what you think is the best solution. Here are some questions I am trying to answer: 1. Where should we share code? What system works best for LabVIEW code and is user friendly enough to not discourage people from using it? Please share links and how-to documents for your preferred site/system. 2. How should we license code? I heard some discussion about the various type of licenses. I am not interested in retaining any rights to code I share and do not want to put any burdens on those who want to use and learn from any code I share. What licence is accepted in the open source community that supports this kind of sharing? 3. Once we post, how do we make our code discoverable? Do we need to post links all over the place or is there a better way? Here is one attempt at making that better you should check out if you have not already: I am not just interested in putting the code out there, but also trying to explain why I think it is worth your time to take a look. I am willing to post on forums, create a blog, even produce some vlogs on YouTube if it is the best option. Please let me know what format would motivate you to take the time to learn about the open source code out there. Either way, thanks for taking the time to read this thread and contribute what you can, even if it is just to follow the discussion and learn from others like I am trying to do. -John

Did they forget to use their 'Where's Jeremy' app?!??

We will miss you. I hope to attend both, but with the move to the later half of the week, if I go to the summit, I will have to miss the last day. :-(

I can't seem to find the post or links to sign up for the LAVA BBQ this year (2018). Is it still on? Thanks for any info...

I'm in! Looking forward to having BBQ and great conversations while not sweating to death in the process for once...

I want to call my installer I built from a project in silent mode. (arguments: /q /acceptlicenses YES) But if the installer has no changes to install I want it to skip silently. Unfortunately the behavior I am seeing is the installer will run and reinstall everytime in this mode. Does anyone know how to get it to try and skip silently if there are no changes needed?

Confirmed that the firewall kills stale connections after 1 hour. I'll add a timestamp to refresh the connection if it is over 55 mins old. Still want to know why the timeout for call by reference is so long. It appears to be 60 seconds and there is no way to change it.

No proxy but there may a firewall. Need to talk to the IT guys. Keep alives would work but the system is not designed for that and it would add to traffic. Especially when across large distances with limited pipes. I wish there was some docs about how long the call by ref timeout is and how to control it. Another option is to store a time-stamp with the refs and refresh them if enough time has elapsed. Wish there was an easier solution.

I could make a simple VI, but there is not much to it. Open app reference followed by open VI reference followed by call by reference. Save the app and vi refs for later. Then wait awhile and try to call the remote VI again with the cached refs. I am sure that IT is to blame for my open connection going bad, but I can't really control them and just need a way to recover quickly. I don't want to incur the cost of opening the app and vi refs for every call. Looking for an alternate solution.